swap prefetching merge plans

swap prefetching merge plans

[Con Kolivas]

On Thu, 23 Mar 2006 03:53 pm, Andrew Morton wrote:
> A look at the -mm lineup for 2.6.17:

> mm-implement-swap-prefetching.patch
> mm-implement-swap-prefetching-fix.patch
> mm-implement-swap-prefetching-tweaks.patch

>   Still don't have a compelling argument for this, IMO.

For those users who feel they do have a compelling argument for it, please 
speak now or I'll end up maintaining this in -ck only forever.  I've come to 
depend on it with my workloads now so I'm never dropping it. There's no point 
me explaining how it is useful yet again, though, because I just end up 
looking like I'm handwaving. It seems a shame for it not to be available to 
all linux users.

Cheers,
Con

Re:swap prefetching merge plans

[Hemmann, Volker Armin]

Hi,

I am just a user, but I would love to see this feature.

After compiling stuff, I have usually some kb in swap (300kb, 360 kb), and 
lots of free ram. But even this few kb make my KDE desktop extremly sluggish. 
It feels, like every byte is fetched individually and always the wrong stuff 
ends in swap.

The only 'workaround' so far is to do a 'swapoff -a&& swapon -a' which not 
only clears swap, but make my box blazzingly fast again (thank you guys, 
besides this little swap annoyance you all do a great job). 

So everything that makes the situation better (swap in of data faster) is 
highly welcome. The CPU is bored most of the time anyway and as I wrote 
above, usually lots of ram are free. So why not use the free ram and free CPU 
cycles?

The compelling argument is: swap is extremly slow. It is so slow that you can 
go out, plant a tree, build a house and father a son while I am waiting for 
some few kb to get fetched from it. Everything that reduces swap access when 
the data is needed, is IMHO a good thing. Oh, and the harddisk is not slow. 
Only swap is.

Glück Auf,
Volker

Re: swap prefetching merge plans

[Nick Piggin]

Hemmann, Volker Armin wrote:
> Hi,
> 
> I am just a user, but I would love to see this feature.
> 
> After compiling stuff, I have usually some kb in swap (300kb, 360 kb), and 
> lots of free ram. But even this few kb make my KDE desktop extremly sluggish. 
> It feels, like every byte is fetched individually and always the wrong stuff 
> ends in swap.
> 

I'm almost positive this wouldn't be the cause of your problems (even a
slow disk could read all these blocks in, randomly, in under 2 seconds,
assuming they're spread from one end of the platters to the other).

The problem is simply the more general one of parts your working set
being paged out (in this case, cached files). Which is something swap
prefetch will not help with.

> The only 'workaround' so far is to do a 'swapoff -a&& swapon -a' which not 
> only clears swap, but make my box blazzingly fast again (thank you guys, 
> besides this little swap annoyance you all do a great job). 
> 
> So everything that makes the situation better (swap in of data faster) is 
> highly welcome. The CPU is bored most of the time anyway and as I wrote 
> above, usually lots of ram are free. So why not use the free ram and free CPU 
> cycles?
> 
> The compelling argument is: swap is extremly slow. It is so slow that you can 
> go out, plant a tree, build a house and father a son while I am waiting for 
> some few kb to get fetched from it. Everything that reduces swap access when 
> the data is needed, is IMHO a good thing. Oh, and the harddisk is not slow. 
> Only swap is.
> 

I'd be stumped if swapoff helps you. Maybe you aren't exaggerating about
the speed of your swap.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: swap prefetching merge plans

[Jesper Juhl]

On 3/23/06, Con Kolivas <kernel@kolivas.org> wrote:
> On Thu, 23 Mar 2006 03:53 pm, Andrew Morton wrote:
> > A look at the -mm lineup for 2.6.17:
>
> > mm-implement-swap-prefetching.patch
> > mm-implement-swap-prefetching-fix.patch
> > mm-implement-swap-prefetching-tweaks.patch
>
> >   Still don't have a compelling argument for this, IMO.
>
> For those users who feel they do have a compelling argument for it, please
> speak now or I'll end up maintaining this in -ck only forever.  I've come to
> depend on it with my workloads now so I'm never dropping it. There's no point
> me explaining how it is useful yet again, though, because I just end up
> looking like I'm handwaving. It seems a shame for it not to be available to
> all linux users.
>

I certainly like it and see a bennefit.
My situation is like this:
 A KDE desktop with OpenOffice, Lyx, Firefox, Eclipse, Gimp & a bunch
of xterms running more or less permanently.
 When I work on kernel stuff I often end up running "make clean ; make
allyesconfig ; make" and the build and especially final link of the
kernel usually kills the box for a while, so I tend to walk away and
come back a while later when it's done.
 Where I see the bennefit of swap prefetch is when I come back to my
box after such a build and pull one of my other running apps back to
the foreground. The apps come back noticably faster when I'm running a
swap prefetching kernel - we are not talking massive amounts of time,
just a few seconds, but it's enough for me to notice when I sometimes
happen to run a mainline kernel without swap prefetch.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: swap prefetching merge plans

[Jan Knutar]

On Thursday 23 March 2006 10:26, Nick Piggin wrote:
> Hemmann, Volker Armin wrote:
> > Hi,
> > 
> > I am just a user, but I would love to see this feature.
> > 
> > After compiling stuff, I have usually some kb in swap (300kb, 360 kb), and 
> > lots of free ram. But even this few kb make my KDE desktop extremly sluggish. 
> > It feels, like every byte is fetched individually and always the wrong stuff 
> > ends in swap.
> > 
> 
> I'm almost positive this wouldn't be the cause of your problems (even a
> slow disk could read all these blocks in, randomly, in under 2 seconds,
> assuming they're spread from one end of the platters to the other).

Maybe he meant 300 megabytes.

Re: swap prefetching merge plans

[Hemmann, Volker Armin]

On Thursday 23 March 2006 12:47, you wrote:
> On Thursday 23 March 2006 10:26, Nick Piggin wrote:
> > Hemmann, Volker Armin wrote:
> > > Hi,
> > >
> > > I am just a user, but I would love to see this feature.
> > >
> > > After compiling stuff, I have usually some kb in swap (300kb, 360 kb),
> > > and lots of free ram. But even this few kb make my KDE desktop extremly
> > > sluggish. It feels, like every byte is fetched individually and always
> > > the wrong stuff ends in swap.
> >
> > I'm almost positive this wouldn't be the cause of your problems (even a
> > slow disk could read all these blocks in, randomly, in under 2 seconds,
> > assuming they're spread from one end of the platters to the other).
>
> Maybe he meant 300 megabytes.

no, I meant kilobytes.

And swapoff really helps.

Some moments of disk activity, and bang, computer is as fast as always again.

But having stuff in swap? konqueror is slow, kmail is slow, opening a konsole 
session, slow. Everything crawls with lots of disk access. 

next time the computer is slow, I could gather some data - if you tell me, 
what is interessting for you, I'll save it.

Glück Auf,
Volker

Re: swap prefetching merge plans

[Francesco Biscani]

On Thursday 23 March 2006 08:04, Con Kolivas wrote:
> For those users who feel they do have a compelling argument for it, please
> speak now or I'll end up maintaining this in -ck only forever.  I've come
> to depend on it with my workloads now so I'm never dropping it. There's no
> point me explaining how it is useful yet again, though, because I just end
> up looking like I'm handwaving. It seems a shame for it not to be available
> to all linux users.

Another "me too" from a desktop user here, for the reasons other people have 
already explained. Please consider it for merging into mainline.

-- 
Dr. Francesco Biscani
Dipartimento di Astronomia
Università di Padova
biscani@pd.astro.it

Re: swap prefetching merge plans

[James Rayner]

On 3/24/06, Francesco Biscani <biscani@pd.astro.it> wrote:
> On Thursday 23 March 2006 08:04, Con Kolivas wrote:
> > For those users who feel they do have a compelling argument for it, please
> > speak now or I'll end up maintaining this in -ck only forever.  I've come
> > to depend on it with my workloads now so I'm never dropping it. There's no
> > point me explaining how it is useful yet again, though, because I just end
> > up looking like I'm handwaving. It seems a shame for it not to be available
> > to all linux users.
>
> Another "me too" from a desktop user here, for the reasons other people have
> already explained. Please consider it for merging into mainline.
>

Another 'me too' from me.

I dont use swap often, or at least I wouldnt think I would. The few
times I do hit swap, it's covered well by prefetch. It covers the
system well after returning from a heavy task, such as a game or
leaving my system to be used as a distributed build system for my
distro. Firefox, Opera, or other big applications if left open, spring
right back, usable almost instantaneously, whereas without prefetch,
there's an annoying and noticable delay.

There doesnt seem to be any compelling arguments against prefetch.
There are a lot of users swearing by it. I maintain packages in the
Arch Linux repositories with prefetch enabled, and i've had no
complaints about it, only praise about how well these kernels handle a
system under load and afterwards.

By concept alone, it's easy to see how swap prefetch can help. Here we
have an implementation in practice, and it's working very well.

James
--
iphitus - ArchCK Maintainer, Arch Developer.
Home:iphitus.loudas.com

Re: swap prefetching merge plans

[Mattia Dongili]

Hello,

On Thu, Mar 23, 2006 at 06:04:36PM +1100, Con Kolivas wrote:
> On Thu, 23 Mar 2006 03:53 pm, Andrew Morton wrote:
> > A look at the -mm lineup for 2.6.17:
> 
> > mm-implement-swap-prefetching.patch
> > mm-implement-swap-prefetching-fix.patch
> > mm-implement-swap-prefetching-tweaks.patch
> 
> >   Still don't have a compelling argument for this, IMO.
> 
> For those users who feel they do have a compelling argument for it, please 
> speak now or I'll end up maintaining this in -ck only forever.  I've come to 

I have just 256MB on this laptop and I know its limits.
IME swap prefetch helps expecially when I need to open some memory
demanding application for just a few mintues (OO.org, gimp on large
images, pretty large builds, any 3D app) and then go back to my usual
<high number> of xterms.

I did definitely noticed the difference when Andrew dropped the patch
the first time. As already said, it seems so natural the idea of
swapping-in when some room is available that I immediately got used to
having this functionality and I support its inclusion.

Thanks
-- 
mattia
:wq!

Re: swap prefetching merge plans

[Rafael J. Wysocki]

Hi,

On Thursday 23 March 2006 08:04, Con Kolivas wrote:
> On Thu, 23 Mar 2006 03:53 pm, Andrew Morton wrote:
> > A look at the -mm lineup for 2.6.17:
> 
> > mm-implement-swap-prefetching.patch
> > mm-implement-swap-prefetching-fix.patch
> > mm-implement-swap-prefetching-tweaks.patch
> 
> >   Still don't have a compelling argument for this, IMO.
> 
> For those users who feel they do have a compelling argument for it, please 
> speak now or I'll end up maintaining this in -ck only forever.  I've come to 
> depend on it with my workloads now so I'm never dropping it. There's no point 
> me explaining how it is useful yet again, though, because I just end up 
> looking like I'm handwaving. It seems a shame for it not to be available to 
> all linux users.

AFAICT, it may help get the system more responsive after resume from suspend
to disk.  However, I'd like to get some hard data to support this, but I have
a little time to test it myself now.  Also I haven't thought about the
methodology yet.

If anyone can help with that, please go for it.

Greetings,
Rafael

Re: swap prefetching merge plans

[Helge Hafting]

Hemmann, Volker Armin wrote:

>On Thursday 23 March 2006 12:47, you wrote:
>  
>
>>On Thursday 23 March 2006 10:26, Nick Piggin wrote:
>>    
>>
>>>Hemmann, Volker Armin wrote:
>>>      
>>>
>>>>Hi,
>>>>
>>>>I am just a user, but I would love to see this feature.
>>>>
>>>>After compiling stuff, I have usually some kb in swap (300kb, 360 kb),
>>>>and lots of free ram. But even this few kb make my KDE desktop extremly
>>>>sluggish. It feels, like every byte is fetched individually and always
>>>>the wrong stuff ends in swap.
>>>>        
>>>>
>>>I'm almost positive this wouldn't be the cause of your problems (even a
>>>slow disk could read all these blocks in, randomly, in under 2 seconds,
>>>assuming they're spread from one end of the platters to the other).
>>>      
>>>
>>Maybe he meant 300 megabytes.
>>    
>>
>
>no, I meant kilobytes.
>
>And swapoff really helps.
>
>Some moments of disk activity, and bang, computer is as fast as always again.
>
>But having stuff in swap? konqueror is slow, kmail is slow, opening a konsole 
>session, slow. Everything crawls with lots of disk access. 
>
>next time the computer is slow, I could gather some data - if you tell me, 
>what is interessting for you, I'll save it.
>  
>
Strange indeed.  300k in swap is nothing - I often enough
have 50M in swap without a slowdown - but then, I don't
run kde. 

Be aware that the 300k in swap doesn't account for all that
is removed from memory.  Linux don't put executable code
in swap - such stuff is simply dropped because it can
be reloaded from the executable files anytime.
I don't think swapoff+swapon helps with that though.

Helge Hafting

Re: swap prefetching merge plans

[Jan Engelhardt]

>> A look at the -mm lineup for 2.6.17:
>
>> mm-implement-swap-prefetching.patch
>> mm-implement-swap-prefetching-fix.patch
>> mm-implement-swap-prefetching-tweaks.patch
>
>>   Still don't have a compelling argument for this, IMO.
>
>For those users who feel they do have a compelling argument for it, please 
>speak now or I'll end up maintaining this in -ck only forever.  I've come to 

When will Staircase go in?



Jan Engelhardt
-- 

Re: swap prefetching merge plans

[Nick Piggin]

Jan Engelhardt wrote:

> 
> When will Staircase go in?
> 

It is in... the queue ;)

-- 
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: swap prefetching merge plans

[Con Kolivas]

On Sunday 26 March 2006 02:24, Nick Piggin wrote:
> Jan Engelhardt wrote:
> > When will Staircase go in?
>
> It is in... the queue ;)

Hah you wish.

No way would I let mainline benefit from something that good. I'm hoarding it 
for -ck only.

Cheers,
Con

Re: swap prefetching merge plans

[Mike Galbraith]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Sun, 2006-03-26 at 10:44 +1100, Con Kolivas wrote:
> On Sunday 26 March 2006 02:24, Nick Piggin wrote:
> > Jan Engelhardt wrote:
> > > When will Staircase go in?
> >
> > It is in... the queue ;)
> 
> Hah you wish.
> 
> No way would I let mainline benefit from something that good. I'm hoarding it 
> for -ck only.

Well, my box doesn't think it's _that_ good.  I just got done doing some
basic testing, and it is most definitely not ready for primetime.  It
has the same problem with sleep as the stock kernel does for instance.

This is bonnie competing with three sleeping cpu hogs.

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  1   3684  13824   4516 818888    0    1  2414  2510 1160  3062 54  5 29 12
 1  0   3684  14892   4528 817888    0    0    28  6940 1248  1779 98  2  0  0
 1  0   3684  13624   4532 819240    0    0     0     0 1097  1586 99  1  0  0
 1  0   3684  14556   4532 818284    0    0     0     0 1181  1709 99  1  0  0
 1  0   3684  13688   4532 819184    0    0     0     0 1193  2011 100  0  0  0
 1  1   3684  14252   4532 818528    0    0   128  5196 1441  1632 98  2  0  0
 1  0   3684  15028   4536 817804    0    0     0    80 1216  1735 99  1  0  0
 1  0   3684  13276   4536 819576    0    0     0     0 1157  1650 99  1  0  0
 1  0   3684  13976   4540 818832    0    0     4     0 1204  1793 99  1  0  0
 1  0   3684  14788   4544 817972    0    0     0     0 1087  1540 100  0  0  0
 2  0   3684  13408   4552 819412    0    0    80  6760 1237  1736 98  2  0  0
 1  0   3684  14260   4552 818596    0    0     0     4 1091  1564 99  1  0  0
 1  0   3684  13144   4556 819712    0    0     0     0 1223  1781 99  1  0  0
 1  0   3684  13704   4548 819176    0    0     0     0 1090  1546 99  1  0  0

(after short read, I see it wasn't allowed to compete)

Needless to say, I interrupted it.

It also fails the attached testcase.

	-Mike

[-- Attachment #2: starve.c --]
[-- Type: text/x-csrc, Size: 715 bytes --]

#include <stdlib.h>
#include <stdio.h>
#include <signal.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/wait.h>

volatile unsigned long loop = 10000000;

void
handler (int n)
{
  if (loop > 0)
    --loop;
}

static int
child (void)
{
  pid_t ppid = getppid ();

  sleep (1);
  while (1)
    kill (ppid, SIGUSR1);
  return 0;
}

int
main (int argc, char **argv)
{
  pid_t child_pid;
  int r;

  loop = argc > 1 ? strtoul (argv[1], NULL, 10) : 10000000;
  printf ("expecting to receive %lu signals\n", loop);

  if ((child_pid = fork ()) == 0)
    exit (child ());

  signal (SIGUSR1, handler);
  while (loop)
    sleep (1);
  r = kill (child_pid, SIGTERM);
  waitpid (child_pid, NULL, 0);
  return 0;
}

Re: swap prefetching merge plans

[Mike Galbraith]

On Sun, 2006-03-26 at 19:08 +1100, Con Kolivas wrote:
> On Sunday 26 March 2006 15:54, Mike Galbraith wrote:
> > On Sun, 2006-03-26 at 10:44 +1100, Con Kolivas wrote:
> > > On Sunday 26 March 2006 02:24, Nick Piggin wrote:
> > > > Jan Engelhardt wrote:
> > > > > When will Staircase go in?
> > > >
> > > > It is in... the queue ;)
> > >
> > > Hah you wish.
> > >
> > > No way would I let mainline benefit from something that good. I'm
> > > hoarding it for -ck only.
> >
> > Well, my box doesn't think it's _that_ good.
> 
> I guess you didn't get the extreme sarcasm in my comment.

I guess so.  I thought you were of the opinion that staircase would be a
good drop-in replacement for the stock scheduler.

> > I just got done doing some 
> > basic testing, and it is most definitely not ready for primetime.
> 
> I guess me criticising your patches made you want to find flaws with my code.

I was simply curious as to how well the damn thing performs Con.  Don't
worry though, I'll never make the mistake of testing and reporting ever
again.

	Later,

	-Mike

Re: swap prefetching merge plans

[Con Kolivas]

On Sunday 26 March 2006 15:54, Mike Galbraith wrote:
> On Sun, 2006-03-26 at 10:44 +1100, Con Kolivas wrote:
> > On Sunday 26 March 2006 02:24, Nick Piggin wrote:
> > > Jan Engelhardt wrote:
> > > > When will Staircase go in?
> > >
> > > It is in... the queue ;)
> >
> > Hah you wish.
> >
> > No way would I let mainline benefit from something that good. I'm
> > hoarding it for -ck only.
>
> Well, my box doesn't think it's _that_ good.

I guess you didn't get the extreme sarcasm in my comment.

> I just got done doing some 
> basic testing, and it is most definitely not ready for primetime.

I guess me criticising your patches made you want to find flaws with my code.

> It 
> has the same problem with sleep as the stock kernel does for instance.

Great to hear I am in such good company.

I don't suppose you know there is an interactive tunable in the full staircase 
set in -ck

Anyway this is all moot. I have no intention of pushing this code to mainline, 
but I thank you for your feedback with respect to it.

Cheers,
Con

Re: swap prefetching merge plans

[Jan Engelhardt]

>> > When will Staircase go in?
>> It is in... the queue ;)
>Hah you wish.
>
>No way would I let mainline benefit from something that good. I'm hoarding it 
>for -ck only.
>

Bad thing is, it's all under GPL, so everyone is free to put it into 
mainline. :p


Jan Engelhardt
-- 

Re: swap prefetching merge plans

[Con Kolivas]

On Sunday 26 March 2006 17:42, Mike Galbraith wrote:
> On Sun, 2006-03-26 at 19:08 +1100, Con Kolivas wrote:
> > I guess me criticising your patches made you want to find flaws with my
> > code.
>
> I was simply curious as to how well the damn thing performs Con.  Don't
> worry though, I'll never make the mistake of testing and reporting ever
> again.

That was a foolishly bitter comment from me that you did absolutely nothing to 
deserve and I humbly apologise.

Con