On Fri, Dec 31, 2004 at 08:12:42AM +1100, Nick Piggin wrote:
> Andrea Arcangeli wrote:
> >This is the forward port to 2.6 of the lowmem_reserved algorithm I
> >invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> >like google (especially without swap) on x86 with >1G of ram, but it's
> >needed in all sort of workloads with lots of ram on x86, it's also
> >needed on x86-64 for dma allocations. This brings 2.6 in sync with
> >latest 2.4.2x.
> >
>
> This looks OK to me. It really simplifies the code there a lot too.
>
> The only questions I have are: should it be on by default? I don't think
> we ever reached an agreement. I'd say yes, after a run in -mm because it
> does potentially fix corner cases where lower zones get filled with un-
> freeable memory which could have been satisfied with higher zones.
Great, thanks for the review! I definitely agree it should be on by
default, I already had an hang report that was solved by more recent
kernels and that probably can only be explained by lowmem_reserve since
there aren't other mm changes in 2.6.5 based trees.
> And second, any chance you could you port it to the mm patches already in
> -mm? Won't be a big job, just some clashes in __alloc_pages...
I already had to port to 2.6.5 too, and that's enough for now unless I
first get a positive ack that it will be merged (if I hadn't more
interesting things to develop, I would be happily porting it).
On Sun, Jan 02, 2005 at 05:32:36PM +0100, Andrea Arcangeli wrote:
> On Fri, Dec 31, 2004 at 08:12:42AM +1100, Nick Piggin wrote:
> > Andrea Arcangeli wrote:
> > >This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > >invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> > >like google (especially without swap) on x86 with >1G of ram, but it's
> > >needed in all sort of workloads with lots of ram on x86, it's also
> > >needed on x86-64 for dma allocations. This brings 2.6 in sync with
> > >latest 2.4.2x.
> > >
> >
> > This looks OK to me. It really simplifies the code there a lot too.
> >
> > The only questions I have are: should it be on by default? I don't think
> > we ever reached an agreement. I'd say yes, after a run in -mm because it
> > does potentially fix corner cases where lower zones get filled with un-
> > freeable memory which could have been satisfied with higher zones.
>
> Great, thanks for the review! I definitely agree it should be on by
> default, I already had an hang report that was solved by more recent
> kernels and that probably can only be explained by lowmem_reserve since
> there aren't other mm changes in 2.6.5 based trees.
>
> > And second, any chance you could you port it to the mm patches already in
> > -mm? Won't be a big job, just some clashes in __alloc_pages...
>
> I already had to port to 2.6.5 too, and that's enough for now unless I
> first get a positive ack that it will be merged (if I hadn't more
> interesting things to develop, I would be happily porting it).
I believe it can be accepted easily if you change the variable names
from protection to lowmem_reserve.
Is there a need for that or its just your taste? :)
On Mon, Jan 03, 2005 at 10:25:18AM -0200, Marcelo Tosatti wrote:
> On Sun, Jan 02, 2005 at 05:32:36PM +0100, Andrea Arcangeli wrote:
> > On Fri, Dec 31, 2004 at 08:12:42AM +1100, Nick Piggin wrote:
> > > Andrea Arcangeli wrote:
> > > >This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > > >invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> > > >like google (especially without swap) on x86 with >1G of ram, but it's
> > > >needed in all sort of workloads with lots of ram on x86, it's also
> > > >needed on x86-64 for dma allocations. This brings 2.6 in sync with
> > > >latest 2.4.2x.
> > > >
> > >
> > > This looks OK to me. It really simplifies the code there a lot too.
> > >
> > > The only questions I have are: should it be on by default? I don't think
> > > we ever reached an agreement. I'd say yes, after a run in -mm because it
> > > does potentially fix corner cases where lower zones get filled with un-
> > > freeable memory which could have been satisfied with higher zones.
> >
> > Great, thanks for the review! I definitely agree it should be on by
> > default, I already had an hang report that was solved by more recent
> > kernels and that probably can only be explained by lowmem_reserve since
> > there aren't other mm changes in 2.6.5 based trees.
> >
> > > And second, any chance you could you port it to the mm patches already in
> > > -mm? Won't be a big job, just some clashes in __alloc_pages...
> >
> > I already had to port to 2.6.5 too, and that's enough for now unless I
> > first get a positive ack that it will be merged (if I hadn't more
> > interesting things to develop, I would be happily porting it).
>
> I believe it can be accepted easily if you change the variable names
> from protection to lowmem_reserve.
>
> Is there a need for that or its just your taste? :)
The naming is in sync with 2.4, I called that feature lowmem_reserve
when I wrote it. Protection doesn't actually mean anything. Memory
protection, mprotect, what?
The object of the feature is to reserve lower memory in function of the
classzone allocation, and in function of the zone we're allocating from.
So lowmem_reserve sounds a much better name. And it wasn't me to change
it, it was the 2.6 kernel calling it differently in the first place.
Note that at first 2.6 was doing stuff very differently from 2.4 too
(and it wasn't working right infact). Now it's in perfect sync with the 2.4
algorightm I wrote originally and so I thought it would be much cleaner
to call it the same way as 2.4, which is more self explanatory too.