On Thu, Dec 18, 2008 at 11:35:49PM -0800, Andrew Morton wrote: > On Fri, 19 Dec 2008 08:29:09 +0100 Nick Piggin <npiggin@xxxxxxx> wrote: > > > Introduce a new page flag, PG_waiters > > Leaving how many? Don't know... I thought the page-flags.h obfuscation project was supposed to make that clearer to work out. There are what, 21 flags used now. If everything is coded properly, then the memory model should automatically kick its metadata out of page flags if it gets too big. But most likely it will just blow up. Probably we want at least a few flags for memory model on 32-bit for smaller systems (big NUMA 32-bit systems probably don't matter much anymore). > fs-cache wants to take two more. fs-cache is getting merged? Wow, I've wanted to review that. When? Aside from artificial benchmarks (which are obviously going to be good), does anybody actually deploy it? What do their before/afters look like I wonder? > How's about we actually work this out, then make PG_waiters the > highest-numbered free one? > > PG_free1, > PG_free2, > ... > PG_waiters > }; > > (or even something really sensitive, like PG_lru) > > So that > > a) we can see how many are left in a robust fashion and > > b) we find out whether PG_waiters (PG_lru?) gets scribbled on by architectures > which borrow upper bits from page.flags for other nefarious purposes. I think if we can just get the memory-model people involved, they can assure us their code automatically scales to any value of __NR_PAGEFLAGS, and suggest a reasonable number of flags we should leave for 32-bit systems. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
