Messages in this thread | | | Date | Thu, 17 Apr 2008 03:50:15 -0700 | From | Andrew Morton <> | Subject | Re: [v2.6.26] what's brewing in x86.git for v2.6.26 |
| |
On Thu, 17 Apr 2008 12:32:03 +0200 Johannes Weiner <hannes@saeurebad.de> wrote:
> Hi, > > Andrew Morton <akpm@linux-foundation.org> writes: > > > - extensive damage to the page-flags patches > > > > Did you check that all architectures and configurations still have > > sufficient page flags for us to be able to consume another one for > > kmemcheck? The MM developers have put much, much effort into avoiding > > running out of flags over numerous years and afaik none of them even know > > that this debug feature is using one of the few remaining ones. > > > > What do we do when we run out? > > Would it be feasible to add another unsigned long to struct page? I > mean, extending such a common structure always sucks, but for > emergency... > > #define PageFoobar(page) test_bit(PG_foobar, &(page)->flags2) > > Of course the essential core flags should always be in ->flags but > perhaps we could have a symbol CONFIG_NEED_EXTRA_PAGE_FLAGS that gets > selected by kmemcheck (and other candidates that are unlikely to be > enabled most of the time) and then #ifndef ->flags2 out. >
Yes, but I think that only applies to PG_tracked.
We may be able to reclaim PG_buddy by putting various fields in the pageframe to idiotic otherwise-cant-happen states. Like
static inline bool PageBuddy(struct page *page) { return page->mapping == (long)&page->private; }
or something. But these things are so overloaded it gets tricky.
| |