redhat 2.4.20 kernel 3.5G patch, bug report on my previous 2.4.18 kernel 3.5G patch

redhat 2.4.20 kernel 3.5G patch, bug report on my previous 2.4.18 kernel 3.5G patch

[Chuck Luciano]

Again, I've been kinda lazy about adding the configuration stuff, but, this patch applied to kernel-2.4.20-18.7.src.rpm will give
you a kernel where PAGE_OFFSET can be set with 2 MB granularity instead of 1GB.

BTW, there is a defect in the 2.4.18 version of this patch in the function get_pgd_slow which doesn't handle the partial PGD
properly. In 2.4.20 the fix for this problem is in the function pgd_alloc. I will probably not have time to back port this fix to
2.4.18.

Anyway, for your fun and amusement, the 2.4.20 patch is working and ready for use. I haven't tried seeing just how far I can push
PAGE_OFFSET yet, but I'd like to see how close I can get to 0xf0000000 and maybe beyond.

Links:

http://www.mrluciano.com/chuck/linux-2.4.18-unaligned.patch
http://www.mrluciano.com/chuck/linux-2.4.20-unaligned.patch
Chuck Luciano

chuck@mrluciano.com

Re: redhat 2.4.20 kernel 3.5G patch, bug report on my previous 2.4.18 kernel 3.5G patch

[Dave Hansen]

On Tue, 2003-08-19 at 10:55, Chuck Luciano wrote:
> Again, I've been kinda lazy about adding the configuration stuff,
> but, this patch applied to kernel-2.4.20-18.7.src.rpm will give
> you a kernel where PAGE_OFFSET can be set with 2 MB granularity
> instead of 1GB.

This sounds familar from somewhere.  A little attribution to the source
of the code would be nice. :) 

> BTW, there is a defect in the 2.4.18 version of this patch in the
> function get_pgd_slow which doesn't handle the partial PGD
> properly. In 2.4.20 the fix for this problem is in the function 
> pgd_alloc. I will probably not have time to back port this fix to
> 2.4.18.

Actually, I would just do what we did in 2.5 and throw away *_pgd_fast()
functions and just use a slab constructor and destructor to handle it
for you.

> Anyway, for your fun and amusement, the 2.4.20 patch is working 
> and ready for use. I haven't tried seeing just how far I can push
> PAGE_OFFSET yet, but I'd like to see how close I can get to 
> 0xf0000000 and maybe beyond.

I know I've done at least 0xf8000000 on 2.5.  

-- 
Dave Hansen
haveblue@us.ibm.com

Re: redhat 2.4.20 kernel 3.5G patch, bug report on my previous 2.4.18 kernel 3.5G patch

[William Lee Irwin III]

On Tue, Aug 19, 2003 at 02:16:58PM -0700, Dave Hansen wrote:
> Actually, I would just do what we did in 2.5 and throw away *_pgd_fast()
> functions and just use a slab constructor and destructor to handle it
> for you.

Please be patient for the preconstruction that works with highpte; I
have code, but am holding back to keep the number of potentially
destabilizing changes simultaneously in the air down to a reasonable
number.


-- wli

RE: redhat 2.4.20 kernel 3.5G patch, bug report on my previous2.4.18 kernel 3.5G patch

[Chuck Luciano]

Dave,

You're right. I did make an attribution when I posted the .18 version
of this, but I didn't this time. So,

	I believe the original code was written by someone named Andrea. It
	was a patch against 2.5.74.

	Dave Hansen and Martin Bligh were very helpful and answered numerous
	emails and gave me numerous pointers.

	Also, Mel Gorman's draft book "Understanding the Linux Virtual 
	Memory Manager" provided much useful context for me to dive into
	this code, and if I may give an unsolicited plug for his book, it's
	well worth buying. :)

Failing to gratefully acknowledge this help was a regrettable oversight.

Thank you,
Chuck Luciano
chuck@mrluciano.com


> -----Original Message-----
> From: Dave Hansen [mailto:haveblue@us.ibm.com]
> Sent: Tuesday, August 19, 2003 3:17 PM
> To: Chuck Luciano
> Cc: Linux-Kernel
> Subject: Re: redhat 2.4.20 kernel 3.5G patch, bug report on my
> previous2.4.18 kernel 3.5G patch
> 
> 
> On Tue, 2003-08-19 at 10:55, Chuck Luciano wrote:
> > Again, I've been kinda lazy about adding the configuration stuff,
> > but, this patch applied to kernel-2.4.20-18.7.src.rpm will give
> > you a kernel where PAGE_OFFSET can be set with 2 MB granularity
> > instead of 1GB.
> 
> This sounds familar from somewhere.  A little attribution to the source
> of the code would be nice. :) 
> 
> > BTW, there is a defect in the 2.4.18 version of this patch in the
> > function get_pgd_slow which doesn't handle the partial PGD
> > properly. In 2.4.20 the fix for this problem is in the function 
> > pgd_alloc. I will probably not have time to back port this fix to
> > 2.4.18.
> 
> Actually, I would just do what we did in 2.5 and throw away *_pgd_fast()
> functions and just use a slab constructor and destructor to handle it
> for you.
> 
> > Anyway, for your fun and amusement, the 2.4.20 patch is working 
> > and ready for use. I haven't tried seeing just how far I can push
> > PAGE_OFFSET yet, but I'd like to see how close I can get to 
> > 0xf0000000 and maybe beyond.
> 
> I know I've done at least 0xf8000000 on 2.5.  
> 
> -- 
> Dave Hansen
> haveblue@us.ibm.com
>