From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 21 Jun 2005 23:00:24 -0700
[ Old email, something I want to bring closure to :-) ] > "David S. Miller" <[EMAIL PROTECTED]> wrote: > > The only thing that sticks out to me in this patch is that > > sparc64 uses a field starting at bit 24 in page->flags to > > determine the cpu which needs a D-cache flush for a page. > > <looks> > > That's a bit hacky. Doesn't it conflict with the way in which we stuff the > page's zone index into the top of page->flags? I guess with a small number > of zones and a smallish number of CPUs you got lucky. > > It'd be safer to use bit 32. I disagree. In fact, using bit 24 is the current optimal place. When page->flags is 64-bit, FLAGS_RESERVED is 32, which means that all of this node, zone, section stuff will be stored in the top 32-bits of the page->flags. The highest defined flag for the bottom 32-bits is PG_uncached which is 19. This leaves bits 24-->31 free to sparc64 to use in this way. It of course limits the number of cpus I support to 256 but that limitation also exists in the form of thread_info()->cpu being a "u8" on sparc64, so not a big deal.
