headers
Andrew Morton | 1 Aug 2004 13:05

Re: [PATCH] token based thrashing control

Rik van Riel <riel <at> redhat.com> wrote:
>
> The following experimental patch implements token based thrashing
>  protection, 

Thanks for this - it is certainly needed.

As you say, qsbench throughput is greatly increased (4x here).  But the old
`make -j4 vmlinux' with mem=64m shows no benefit at all.

I figured it was the short-lived processes, so I added the below, which
passes the token to the child across exec, and back to the parent on exit. 
Although it appears to work correctly, it too make no difference.

btw, in page_referenced_one():

+	if (mm != current->mm && has_swap_token(mm))
+		referenced++;

what's the reason for the `mm != current->mm' test?

diff -puN fs/exec.c~token-based-thrashing-control-inheritance fs/exec.c
--- 25/fs/exec.c~token-based-thrashing-control-inheritance	2004-08-01 03:42:04.191461248 -0700
+++ 25-akpm/fs/exec.c	2004-08-01 03:42:04.199460032 -0700
 <at>  <at>  -1146,6 +1146,7  <at>  <at>  int do_execve(char * filename,

 		/* execve success */
 		security_bprm_free(&bprm);
+		take_swap_token();
 		return retval;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arjan van de Ven | 1 Aug 2004 13:13
Picon
Favicon

Re: [PATCH] token based thrashing control


> btw, in page_referenced_one():
> 
> +	if (mm != current->mm && has_swap_token(mm))
> +		referenced++;
> 
> what's the reason for the `mm != current->mm' test?
> 

so that you can steal pages from yourself if you really need to, say if
your own working set is bigger than ram.
Permalink | Reply | 0 comments |
headers
Rik van Riel | 1 Aug 2004 15:02
Picon
Favicon

Re: [PATCH] token based thrashing control

On Fri, 30 Jul 2004, Rik van Riel wrote:

> I have run a very unscientific benchmark on my system to test
> the effectiveness of the patch, timing how a 230MB two-process
> qsbench run takes, with and without the token thrashing
> protection present.
> 
> normal 2.6.8-rc2:	6m45s
> 2.6.8-rc2 + token:	4m24s

OK, I've now also ran day-long kernel compilate tests,
3 times each with make -j 10, 20, 30, 40, 50 and 60 on
my dual pIII w/ 384 MB and a 180 MB named in the background.

For make -j 10 through make -j 50 the differences are in
the noise, basically giving the same result for each kernel.

However, for make -j 60 there's a dramatic difference between
a kernel with the token based swapout and a kernel without.

normal 2.6.8-rc2:	1h20m runtime / ~26% CPU use average
2.6.8-rc2 + token:	  42m runtime / ~52% CPU use average

Time to dig out a dedicated test machine at the office and
do some testing with (RE-)AIM7, I wonder if the max number
of users supported will grow...

--

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik van Riel | 1 Aug 2004 23:52
Picon
Favicon

Re: [PATCH] token based thrashing control

On Sun, 1 Aug 2004, Andrew Morton wrote:
> Rik van Riel <riel <at> redhat.com> wrote:
> >
> > The following experimental patch implements token based thrashing
> >  protection, 
> 
> Thanks for this - it is certainly needed.

I'm glad you like it ;)

> As you say, qsbench throughput is greatly increased (4x here).  But the old
> `make -j4 vmlinux' with mem=64m shows no benefit at all.

I tested increasing make loads on my system here.  The system
is a dual pIII with 384MB RAM and a 180MB named daemon in the
background.

With -j 10, 20, 30, 40 and 50 the patch didn't make much of a
difference at all.  However, with 'make -j 60' it sped up the
average compile time about a factor of 2, from 1:20 down to
40 minutes.  CPU consumption also went up from ~26% to over 50%.

> I figured it was the short-lived processes, so I added the below, which
> passes the token to the child across exec, and back to the parent on exit. 
> Although it appears to work correctly, it too make no difference.

I've got some ideas for potential improvement, too.  However,
I'd like to get the simplest code tested first ;)

> btw, in page_referenced_one():
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 2 Aug 2004 02:56

Re: [PATCH] token based thrashing control

Rik van Riel <riel <at> redhat.com> wrote:
>
> On Fri, 30 Jul 2004, Rik van Riel wrote:
> 
>  > I have run a very unscientific benchmark on my system to test
>  > the effectiveness of the patch, timing how a 230MB two-process
>  > qsbench run takes, with and without the token thrashing
>  > protection present.
>  > 
>  > normal 2.6.8-rc2:	6m45s
>  > 2.6.8-rc2 + token:	4m24s
> 
>  OK, I've now also ran day-long kernel compilate tests,
>  3 times each with make -j 10, 20, 30, 40, 50 and 60 on
>  my dual pIII w/ 384 MB and a 180 MB named in the background.
> 
>  For make -j 10 through make -j 50 the differences are in
>  the noise, basically giving the same result for each kernel.
> 
>  However, for make -j 60 there's a dramatic difference between
>  a kernel with the token based swapout and a kernel without.
> 
>  normal 2.6.8-rc2:	1h20m runtime / ~26% CPU use average
>  2.6.8-rc2 + token:	  42m runtime / ~52% CPU use average

OK.  My test is usually around 50-60% CPU occupancy so we're not gaining in
the moderate swapping range.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik van Riel | 2 Aug 2004 03:36
Picon
Favicon

Re: [PATCH] token based thrashing control

On Sun, 1 Aug 2004, Andrew Morton wrote:
> Rik van Riel <riel <at> redhat.com> wrote:

> >  However, for make -j 60 there's a dramatic difference between
> >  a kernel with the token based swapout and a kernel without.
> > 
> >  normal 2.6.8-rc2:	1h20m runtime / ~26% CPU use average
> >  2.6.8-rc2 + token:	  42m runtime / ~52% CPU use average
> 
> OK.  My test is usually around 50-60% CPU occupancy so we're not gaining
> in the moderate swapping range.

I wonder if measuring minor faults too would help here ...

Btw, here's a slightly updated patch.  It's got the definition
for put_swap_token fixed for !CONFIG_SWAP and calls put_swap_token
before mmput.

I also cut the 4G/4G split line out of the mm/Makefile patch chunk,
so that should now apply better.

It doesn't have any functional changes I'm aware of.

--- linux-2.6.7/include/linux/swap.h.token	2004-07-30 13:22:17.000000000 -0400
+++ linux-2.6.7/include/linux/swap.h	2004-08-01 21:28:29.411274311 -0400
 <at>  <at>  -204,6 +204,27  <at>  <at> 
 extern struct page * lookup_swap_cache(swp_entry_t);
 extern struct page * read_swap_cache_async(swp_entry_t, struct vm_area_struct *vma,
 					   unsigned long addr);
+/* linux/mm/thrash.c */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Con Kolivas | 2 Aug 2004 04:52

Re: [PATCH] token based thrashing control

Andrew Morton wrote:
> Rik van Riel <riel <at> redhat.com> wrote:
> 
>>On Fri, 30 Jul 2004, Rik van Riel wrote:
>>
>> > I have run a very unscientific benchmark on my system to test
>> > the effectiveness of the patch, timing how a 230MB two-process
>> > qsbench run takes, with and without the token thrashing
>> > protection present.
>> > 
>> > normal 2.6.8-rc2:	6m45s
>> > 2.6.8-rc2 + token:	4m24s
>>
>> OK, I've now also ran day-long kernel compilate tests,
>> 3 times each with make -j 10, 20, 30, 40, 50 and 60 on
>> my dual pIII w/ 384 MB and a 180 MB named in the background.
>>
>> For make -j 10 through make -j 50 the differences are in
>> the noise, basically giving the same result for each kernel.
>>
>> However, for make -j 60 there's a dramatic difference between
>> a kernel with the token based swapout and a kernel without.
>>
>> normal 2.6.8-rc2:	1h20m runtime / ~26% CPU use average
>> 2.6.8-rc2 + token:	  42m runtime / ~52% CPU use average
> 
> 
> OK.  My test is usually around 50-60% CPU occupancy so we're not gaining in
> the moderate swapping range.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik van Riel | 2 Aug 2004 05:33
Picon
Favicon

Re: [PATCH] token based thrashing control

On Mon, 2 Aug 2004, Con Kolivas wrote:

> We have some results that need interpreting with contest.
> mem_load:
> Kernel    [runs]	Time	CPU%	Loads	LCPU%	Ratio
> 2.6.8-rc2      4	78	146.2	94.5	4.7	1.30
> 2.6.8-rc2t     4	318	40.9	95.2	1.3	5.13
> 
> The "load" with mem_load is basically trying to allocate 110% of free 
> ram, so the number of "loads" although similar is not a true indication 
> of how much ram was handed out to mem_load. What is interesting is that 
> since mem_load runs continuously and constantly asks for too much ram it 
> seems to be receiving the token most frequently in preference to the cc 
> processes which are short lived. I'd say it is quite hard to say 
> convincingly that this is bad because the point of this patch is to 
> prevent swap thrash.

It may be worth trying with a shorter token timeout
time - maybe even keeping the long ineligibility ?

--

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Con Kolivas | 2 Aug 2004 07:13

Re: [PATCH] token based thrashing control

Rik van Riel wrote:
> On Mon, 2 Aug 2004, Con Kolivas wrote:
> 
> 
>>We have some results that need interpreting with contest.
>>mem_load:
>>Kernel    [runs]	Time	CPU%	Loads	LCPU%	Ratio
>>2.6.8-rc2      4	78	146.2	94.5	4.7	1.30
>>2.6.8-rc2t     4	318	40.9	95.2	1.3	5.13
>>
>>The "load" with mem_load is basically trying to allocate 110% of free 
>>ram, so the number of "loads" although similar is not a true indication 
>>of how much ram was handed out to mem_load. What is interesting is that 
>>since mem_load runs continuously and constantly asks for too much ram it 
>>seems to be receiving the token most frequently in preference to the cc 
>>processes which are short lived. I'd say it is quite hard to say 
>>convincingly that this is bad because the point of this patch is to 
>>prevent swap thrash.
> 
> 
> It may be worth trying with a shorter token timeout
> time - maybe even keeping the long ineligibility ?

Give them a "refractory" bit which is set if they take the token? Next 
time they try to take the token unset the refractory bit instead of 
taking the token.

Con
Permalink | Reply | 0 comments |
headers
Con Kolivas | 2 Aug 2004 07:18

Re: [PATCH] token based thrashing control

Con Kolivas wrote:
> Rik van Riel wrote:
> 
>> On Mon, 2 Aug 2004, Con Kolivas wrote:
>>
>>
>>> We have some results that need interpreting with contest.
>>> mem_load:
>>> Kernel    [runs]    Time    CPU%    Loads    LCPU%    Ratio
>>> 2.6.8-rc2      4    78    146.2    94.5    4.7    1.30
>>> 2.6.8-rc2t     4    318    40.9    95.2    1.3    5.13
>>>
>>> The "load" with mem_load is basically trying to allocate 110% of free 
>>> ram, so the number of "loads" although similar is not a true 
>>> indication of how much ram was handed out to mem_load. What is 
>>> interesting is that since mem_load runs continuously and constantly 
>>> asks for too much ram it seems to be receiving the token most 
>>> frequently in preference to the cc processes which are short lived. 
>>> I'd say it is quite hard to say convincingly that this is bad because 
>>> the point of this patch is to prevent swap thrash.
>>
>>
>>
>> It may be worth trying with a shorter token timeout
>> time - maybe even keeping the long ineligibility ?
> 
> 
> Give them a "refractory" bit which is set if they take the token? Next 
> time they try to take the token unset the refractory bit instead of 
> taking the token.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane