On Mon, 21 Jan 2008, Andi Kleen wrote: > > It's a first shot so it might not yet be perfect - although so far it > > looks good in testing on 4-5 testsystems here, on mixed 64-bit and > > 32-bit boxes. Doing it this way was a pretty straightforward process, it > > took less than an hour - and the end result feels much better in terms > > of maintainability. > > You still kept Venki's redundant 32bit reference count change for 32bit. > The code handled that already by doing reserved bits check.
Hmm. Which patch are you referring to ? There is no patch from Venki in x86.git which touches the pageattr code. > IMHO it would have been cleaner to also do that for the 64bit version > instead of abusing the reference counting for this (like my > "CPA Handle 4K split pages at boot on 64bit" patch did). I don't understand what you mean. The "CPA Handle 4K split pages at boot on 64bit" patch is in x86.git: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commit;h=360b371f73b96c400c6a8fc19ea334d083c65c92 Please clarify. > > I left the clflush feature bits out for now - fixes and cleanups go > > first. We first need to see whether this is robust enough before making > > other changes to c_p_a(). There's enough on the arch/x86 plate for > > v2.6.25 already - we can try the clflush optimizations in v2.6.26. > > (since there's no high-freq in-kernel user of the c_p_a() API at the > > moment, there's no pressing need for this either.) > > Ok I'll redo it. Thank you for your support. > > Probably in larger chunks now though -- with your somewhat > random patching applying methology larger small grained series are just too > painful for me. Please keep them fine-grained and keep fixes separate and prior to features. > First priority will be gbpages on top of it. First priority is getting CPA and PAT consolidated before we put new functionality on top of it. This implies a possible unification of the 32 and 64 bit code as well. There is no real good reason to have different implementations for those. > I would appreciate if you could either prevent or warn against further > wide scale changes on these files before .26 then -- otherwise I'll have > again play catch up with a relatively large patchkit. FYI, the consolidation of CPA and PAT is changing that code, so flux is expected. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
