Re: CPA boot crash (was: [PATCH] [0/36] Great change_page_attr patchseries v3)

[Thomas Gleixner]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/