vm-28 for 2.4.19pre1

vm-28 for 2.4.19pre1

[Andrea Arcangeli]

This patch includes all my latest VM developement against 2.4.19pre1. I
would suggest it for inclusion in pre2. I don't have the time right now
to split it into little pieces, but I can do that in the weekend or next
week if you prefer (tomorrow I'll be offline).

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.19pre1/vm-28

Andrea

Re: vm-28 for 2.4.19pre1

[Marcelo Tosatti]

On Thu, 28 Feb 2002, Andrea Arcangeli wrote:

> This patch includes all my latest VM developement against 2.4.19pre1. I
> would suggest it for inclusion in pre2. I don't have the time right now
> to split it into little pieces, but I can do that in the weekend or next
> week if you prefer (tomorrow I'll be offline).

I would prefer to have it splitted in separate parts _with_ explanations.

Thanks a lot

Re: vm-28 for 2.4.19pre1

[Christoph Hellwig]

Hi Andrea,

In article <20020228174607.X1705@inspiron.school.suse.de> you wrote:
> This patch includes all my latest VM developement against 2.4.19pre1. I
> would suggest it for inclusion in pre2. I don't have the time right now
> to split it into little pieces, but I can do that in the weekend or next
> week if you prefer (tomorrow I'll be offline).
>
> 	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.19pre1/vm-28

Could you actually explain what it changes, especially as it isn't
really commented very well..

Despite of the above I already have some nitpicks:

 - couldn't you make inc_nr_active_pages/dec_nr_active_pages/
	inc_nr_inactive_pages/dec_nr_inactive_pages inlines?
   The current macro abuse isn't nice.
 - in mm/memory.c (the 1141 chunk) you introduced a race.


-- 
Of course it doesn't work. We've performed a software upgrade.

Re: vm-28 for 2.4.19pre1

[Andrea Arcangeli]

On Thu, Feb 28, 2002 at 08:07:30PM +0100, Christoph Hellwig wrote:
>  - couldn't you make inc_nr_active_pages/dec_nr_active_pages/
> 	inc_nr_inactive_pages/dec_nr_inactive_pages inlines?
>    The current macro abuse isn't nice.

I just wanted to be sure to get the very best compilation (but yes, gcc
should be good enough anyways, so I'm fine to make it an inline instead
of a macro).

>  - in mm/memory.c (the 1141 chunk) you introduced a race.

I don't think so, that's a safe and worthwhile optimization (allows
minor swapins while swapcache is under swapout, that's perfectly safe
and it helps a lot).  There's no race there.

Andrea