On Tue, 2004-06-01 at 01:30, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > Well, at the "expense" of paging out unused memory. I don't see
> > any swapin.
>
> On a slow system with small memory you quite often see swapped out
> applications like for example a kopete messenger windows. Once you click on
> it, it takes 10sec or more to get responsive again. Of course its a slow
> system, but gradually paging out and forgetting image pages has that effecct
> on faster systems too, makes the desktop sluggish.
I guess we have a design problem right here.We could add per-process
swappiness attribute.That swap thread becomes boring coz we're looking
globally what's going wrong locally.
FabF
On Tue, 01 Jun 2004 20:36:23 +0200, FabF said:
> I guess we have a design problem right here.We could add per-process
> swappiness attribute.That swap thread becomes boring coz we're looking
> globally what's going wrong locally.
Hmm.. do we need to worry about the same DoS issues we need to worry about with
mlock and friends? I know I can trust myself to not do stupid things to said
flags on my laptop (well... not twice anyhow ;). On the other hand, I have
systems with clueless users, and the even more dangerous half-clued users. And
then I have a bunch of machines in our security lab, where Bad Things happen
all the time...
On Tue, 2004-06-01 at 21:02, [email protected] wrote:
> On Tue, 01 Jun 2004 20:36:23 +0200, FabF said:
>
> > I guess we have a design problem right here.We could add per-process
> > swappiness attribute.That swap thread becomes boring coz we're looking
> > globally what's going wrong locally.
>
> Hmm.. do we need to worry about the same DoS issues we need to worry about with
> mlock and friends? I know I can trust myself to not do stupid things to said
> flags on my laptop (well... not twice anyhow ;). On the other hand, I have
> systems with clueless users, and the even more dangerous half-clued users. And
> then I have a bunch of machines in our security lab, where Bad Things happen
> all the time...
I was thinking about some rule e.g. any process using libX* isn't
swapped to disk until OOM ...
On Tue, 01 Jun 2004 21:53:32 +0200, FabF said:
> I was thinking about some rule e.g. any process using libX* isn't
> swapped to disk until OOM ...
Odd.. some of the processes that I'd want kept in memory use libX*,
but others that also use it are at the top of my list of things to migrate
out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
disk after extended inactivity - but if my window manager gets swapped
out, I get peeved when focus-follows-mouse doesn't and my typing goes
into the wrong window or some such... ;)
And that rule doesn't even help much - as it will cause at least some X
servers themselves to get swapped out. Here's the list for my X server
at the moment, as reported by lsof:
X 13886 root txt REG 254,1 1960870 1966 /usr/X11R6/bin/Xorg
X 13886 root mem REG 254,5 105700 12388 /lib/ld-2.3.3.so
X 13886 root mem REG 254,5 50944 12530 /lib/libnss_files-2.3.3.so
X 13886 root mem REG 254,1 64040 1347 /usr/lib/libz.so.1.2.1.1
X 13886 root mem REG 254,5 212972 53335 /lib/tls/libm-2.3.3.so
X 13886 root mem REG 254,5 28008 12513 /lib/libpam.so.0.77
X 13886 root mem REG 254,5 15008 12471 /lib/libdl-2.3.3.so
X 13886 root mem REG 254,5 8332 12515 /lib/libpam_misc.so.0.77
X 13886 root mem REG 254,5 29660 12511 /lib/libgcc_s-3.3.3-20040413.so.1
X 13886 root mem REG 254,5 1451868 53258 /lib/tls/libc-2.3.3.so
X 13886 root mem REG 254,1 647652 32015 /usr/X11R6/lib/modules/extensions/libglx.so.1.0.5341
X 13886 root mem REG 254,1 4954876 8362 /usr/lib/tls/libGLcore.so.1.0.5341
Nope, no libX* here... ;)
It's a lot harder than it looks, which explains why we haven't gotten it right
yet...
On Tue, 2004-06-01 at 22:00, [email protected] wrote:
> On Tue, 01 Jun 2004 21:53:32 +0200, FabF said:
>
> > I was thinking about some rule e.g. any process using libX* isn't
> > swapped to disk until OOM ...
>
> Odd.. some of the processes that I'd want kept in memory use libX*,
> but others that also use it are at the top of my list of things to migrate
> out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
> disk after extended inactivity - but if my window manager gets swapped
> out, I get peeved when focus-follows-mouse doesn't and my typing goes
> into the wrong window or some such... ;)
>
> And that rule doesn't even help much - as it will cause at least some X
> servers themselves to get swapped out. Here's the list for my X server
> at the moment, as reported by lsof:
>
> X 13886 root txt REG 254,1 1960870 1966 /usr/X11R6/bin/Xorg
> X 13886 root mem REG 254,5 105700 12388 /lib/ld-2.3.3.so
> X 13886 root mem REG 254,5 50944 12530 /lib/libnss_files-2.3.3.so
> X 13886 root mem REG 254,1 64040 1347 /usr/lib/libz.so.1.2.1.1
> X 13886 root mem REG 254,5 212972 53335 /lib/tls/libm-2.3.3.so
> X 13886 root mem REG 254,5 28008 12513 /lib/libpam.so.0.77
> X 13886 root mem REG 254,5 15008 12471 /lib/libdl-2.3.3.so
> X 13886 root mem REG 254,5 8332 12515 /lib/libpam_misc.so.0.77
> X 13886 root mem REG 254,5 29660 12511 /lib/libgcc_s-3.3.3-20040413.so.1
> X 13886 root mem REG 254,5 1451868 53258 /lib/tls/libc-2.3.3.so
> X 13886 root mem REG 254,1 647652 32015 /usr/X11R6/lib/modules/extensions/libglx.so.1.0.5341
> X 13886 root mem REG 254,1 4954876 8362 /usr/lib/tls/libGLcore.so.1.0.5341
>
> Nope, no libX* here... ;)
>
> It's a lot harder than it looks, which explains why we haven't gotten it right
> yet...
>
Boring....You can't have X root layer swapped to disk as it's often used
! Some quick lsof | grep "libX" gives all frontal applications 'swapping
sensible' .fuser can do 'user resource reverse'.Kernel _can_ 'appl.
resource reverse' as well.
PS: I'm not talking about inactive desktop box.Such box has to be rl 3
and is not meant to be user (geek) relevant :)
FabF
On Tue, 01 Jun 2004 22:14:26 +0200, FabF said:
> Boring....You can't have X root layer swapped to disk as it's often used
> ! Some quick lsof | grep "libX" gives all frontal applications 'swapping
> sensible' .fuser can do 'user resource reverse'.Kernel _can_ 'appl.
> resource reverse' as well.
The point you're missing is that if you use a rule such as "everything using
libX* isn't swappable", then the X *server* is suddenly the prime candidate for
swapping out (as it's quite likely the biggest user of memory not using libX*).
(Anybody who ever had the OOM killer whomp their X server to free up space
fast when the *real* problem was a cluster of 6 or 8 "large but still smaller
than the X server" processes knows exactly what I mean... ;)
> PS: I'm not talking about inactive desktop box.Such box has to be rl 3
> and is not meant to be user (geek) relevant :)
So you're saying that I should have kicked my laptop down to runlevel 3 just
because I went across the hall to the machine room to help get a few servers
into racks? Or every time I go into a meeting, or get stuck on a longish phone
call?
Also, be *very* careful equating "user" with "geek" - at least some of us are
trying to produce systems that suit the needs of non-geek users....
On Tue, 2004-06-01 at 22:22, [email protected] wrote:
> On Tue, 01 Jun 2004 22:14:26 +0200, FabF said:
>
> > Boring....You can't have X root layer swapped to disk as it's often used
> > ! Some quick lsof | grep "libX" gives all frontal applications 'swapping
> > sensible' .fuser can do 'user resource reverse'.Kernel _can_ 'appl.
> > resource reverse' as well.
>
> The point you're missing is that if you use a rule such as "everything using
> libX* isn't swappable", then the X *server* is suddenly the prime candidate for
> swapping out (as it's quite likely the biggest user of memory not using libX*).
> (Anybody who ever had the OOM killer whomp their X server to free up space
> fast when the *real* problem was a cluster of 6 or 8 "large but still smaller
> than the X server" processes knows exactly what I mean... ;)
>
> > PS: I'm not talking about inactive desktop box.Such box has to be rl 3
> > and is not meant to be user (geek) relevant :)
>
> So you're saying that I should have kicked my laptop down to runlevel 3 just
> because I went across the hall to the machine room to help get a few servers
> into racks? Or every time I go into a meeting, or get stuck on a longish phone
> call?
>
> Also, be *very* careful equating "user" with "geek" - at least some of us are
> trying to produce systems that suit the needs of non-geek users....
>
As I said, I think this thread is "becoming offtopic" but what can be
interesting is the swapping problem fragmentation :
1.Global inactivity (what you're talking about)
2.Application isolation (what we're talking about).
Geek or not, someone backgrounding an application doesn't want it to
down the box for X seconds some minutes later when it comes back and
such things arrive many times a day.Maybe you've got an idea about a
better rule(s) then ? (I mean for the 2 cases)
On Tue, 01 Jun 2004 23:15:36 +0200, FabF said:
> 1.Global inactivity (what you're talking about)
> 2.Application isolation (what we're talking about).
Again, be careful there - I wasn't the one who said inactive boxes should be in RL3. ;)
And just because I may not be typing on the keyboard doesn't mean that things
are in fact globally inactive - gkrellm is still running, and it has a plugin
monitoring the CPU temperature and adjusting the fan speed as needed, and new
mail is arriving in the background and causing status changes in my MUA.
And yes, said activity tends to keep the gkrellm and MUA pages "hot" and prevent
their swapping out. The problem is that other processes are also doing stuff
in the background for me - but there's no really good way for the system to
know that I consider the gkrellm lages to be "more important" than those
pages taken up by xclock....
> Geek or not, someone backgrounding an application doesn't want it to
> down the box for X seconds some minutes later when it comes back and
> such things arrive many times a day.
Yes, but a solution to that really *should* take into account that some things
will only down the *app* (if OpenOffice is paging in, I can still interact with
the system if X and my window manager and an xterm aren't paged out), whereas
other things will effectively down the *system* as far as the user is concerned (if
X and/or my window manager are paged out, I'm *stuck* till they come back in).
> Maybe you've got an idea about a
> better rule(s) then ? (I mean for the 2 cases)
I admit I have slacked and haven't tried Nick Piggin's MM patches - others have
commented that those work well. I am however quite sure that the Really Right
Answer will require much greater subtlety than a rule like "if it uses libX it
shouldn't be swapped out"....
In article <[email protected]> you wrote:
> out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
> disk after extended inactivity - but if my window manager gets swapped
> out, I get peeved when focus-follows-mouse doesn't and my typing goes
> into the wrong window or some such... ;)
Yes but: your wm is so often used/activated it will not get swaped out.
But if your mouse passes over mozilla and tries to focus it, then you will
feel the pain of a swapped-out x program.
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
[email protected] said on Tue, 01 Jun 2004 15:02:48 -0400:
> --==_Exmh_482188856P
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, 01 Jun 2004 20:36:23 +0200, FabF said:
>
> > I guess we have a design problem right here.We could add per-process
> > swappiness attribute.That swap thread becomes boring coz we're looking
> > globally what's going wrong locally.
>
> Hmm.. do we need to worry about the same DoS issues we need to worry about with
> mlock and friends? I know I can trust myself to not do stupid things to said
> flags on my laptop (well... not twice anyhow ;). On the other hand, I have
> systems with clueless users, and the even more dangerous half-clued users. And
> then I have a bunch of machines in our security lab, where Bad Things happen
> all the time...
I do often get frustrated that the DoS card is brought up to kill a
potentially useful solution. I think there should be a flag in KConfig
saying "This machine will be a server"/"This machine will be mostly a
single user desktop machine". In the latter, you can enable all these
vm/etc heuristics that will help out mozilla/X/your favourite
bloat-ware, but potentially enable a DoS attack, and in the former,
you stay conservative.
I can't rememeber the situation that I was last annoyed by someone
saying "but what about a DoS?"...
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Entropy requires no maintenance.
-- Markoff Chaney
On Wed, 2004-06-02 at 01:17, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
> > disk after extended inactivity - but if my window manager gets swapped
> > out, I get peeved when focus-follows-mouse doesn't and my typing goes
> > into the wrong window or some such... ;)
>
> Yes but: your wm is so often used/activated it will not get swaped out.
> But if your mouse passes over mozilla and tries to focus it, then you will
> feel the pain of a swapped-out x program.
>
Exactly !
Does autoregulated VM swap. patch could help here ?
FabF
> Greetings
> Bernd
On Wed, 2 Jun 2004 15:38, FabF wrote:
> On Wed, 2004-06-02 at 01:17, Bernd Eckenfels wrote:
> > In article <[email protected]> you
wrote:
> > > out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
> > > disk after extended inactivity - but if my window manager gets swapped
> > > out, I get peeved when focus-follows-mouse doesn't and my typing goes
> > > into the wrong window or some such... ;)
> >
> > Yes but: your wm is so often used/activated it will not get swaped out.
> > But if your mouse passes over mozilla and tries to focus it, then you
> > will feel the pain of a swapped-out x program.
>
> Exactly !
> Does autoregulated VM swap. patch could help here ?
Unless you are pushing the limits of your available ram by your usage pattern
then yes the autoregulated swappiness patch should help.
available here:
http://ck.kolivas.org/patches/2.6/2.6.7-rc2/patch-2.6.7-rc2-am11
Just a brief word that might clarify things for people. It seems this huge
swap discussion centres around 2 different arguments. Akpm has said that the
correct way for the vm to behave is that of swappiness=100. Desktop users
note they have less swap out of the programs they use with swappiness 0 or
their swap turned off. When your swappiness is set high, the current vm
decisions are the fastest they can be, but when you go back to your
applications they will take longer to restart. When your swappiness is set
low your applications will restart rapidly, but the current vm will be doing
more work and be slower. Most benchmarks will show the latter, but most
desktop users will feel the former and not really notice the latter.
Try the little experiment to see: Boot with mem=128M and try to compile a 2.6
kernel with all the debugging symbols option enabled - do this with
swappiness set to 0 and then at 100. You'll see it compile much faster at
100. Yet you know that if you set your swappiness to 0 mozilla will load
faster next time you use it on your desktop during your normal usage pattern
(of course you'd probably be using mozilla on a system with a bit more than
128M ram but this helps demonstrate the point).
Does this explain in coarse examples to the desktop users why ideal systems
shouldn't be swap disabled or swappiness=0 ?
The autoregulated swappiness patch tries to get some sort of common ground,
where it sacrifices performance slightly currently to improve what happens
the next time you use your machine substantially. Because it changes with the
amount of application pages in ram, it will not increasingly sacrifice
performance when your memory is full with application pages. What it will not
do is improve the swap thrash situation when you have grossly overloaded your
ram.
Con
Quote from Con Kolivas <[email protected]>:
> Does this explain in coarse examples to the desktop users why ideal systems
> shouldn't be swap disabled or swappiness=0 ?
Yes, except in the case where you are processing a small, (relative to
physical RAM), dataset, and not even touching all physical RAM.
(I admit, this isn't really typical desktop usage, though).
John.
On Wed, 2 Jun 2004 22:22, John Bradford wrote:
> Quote from Con Kolivas <[email protected]>:
> > Does this explain in coarse examples to the desktop users why ideal
> > systems shouldn't be swap disabled or swappiness=0 ?
>
> Yes, except in the case where you are processing a small, (relative to
> physical RAM), dataset, and not even touching all physical RAM.
>
> (I admit, this isn't really typical desktop usage, though).
Well there is no doubt that there are some unique scenarios where an
algorithmic setting will not be as good as a single static setting; and
that's why I put in the option of disabling the auto swappiness. I believe
our proc settings in the kernel should not need to be adjusted for the
majority of cases, though.
Con
On Wed, 2004-06-02 at 13:42, Con Kolivas wrote:
> On Wed, 2 Jun 2004 15:38, FabF wrote:
> > On Wed, 2004-06-02 at 01:17, Bernd Eckenfels wrote:
> > > In article <[email protected]> you
> wrote:
> > > > out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
> > > > disk after extended inactivity - but if my window manager gets swapped
> > > > out, I get peeved when focus-follows-mouse doesn't and my typing goes
> > > > into the wrong window or some such... ;)
> > >
> > > Yes but: your wm is so often used/activated it will not get swaped out.
> > > But if your mouse passes over mozilla and tries to focus it, then you
> > > will feel the pain of a swapped-out x program.
> >
> > Exactly !
> > Does autoregulated VM swap. patch could help here ?
>
> Unless you are pushing the limits of your available ram by your usage pattern
> then yes the autoregulated swappiness patch should help.
>
> available here:
> http://ck.kolivas.org/patches/2.6/2.6.7-rc2/patch-2.6.7-rc2-am11
>
> Just a brief word that might clarify things for people. It seems this huge
> swap discussion centres around 2 different arguments. Akpm has said that the
> correct way for the vm to behave is that of swappiness=100. Desktop users
> note they have less swap out of the programs they use with swappiness 0 or
> their swap turned off. When your swappiness is set high, the current vm
> decisions are the fastest they can be, but when you go back to your
> applications they will take longer to restart. When your swappiness is set
> low your applications will restart rapidly, but the current vm will be doing
> more work and be slower. Most benchmarks will show the latter, but most
> desktop users will feel the former and not really notice the latter.
>
> Try the little experiment to see: Boot with mem=128M and try to compile a 2.6
> kernel with all the debugging symbols option enabled - do this with
> swappiness set to 0 and then at 100. You'll see it compile much faster at
> 100. Yet you know that if you set your swappiness to 0 mozilla will load
> faster next time you use it on your desktop during your normal usage pattern
> (of course you'd probably be using mozilla on a system with a bit more than
> 128M ram but this helps demonstrate the point).
>
> Does this explain in coarse examples to the desktop users why ideal systems
> shouldn't be swap disabled or swappiness=0 ?
>
> The autoregulated swappiness patch tries to get some sort of common ground,
> where it sacrifices performance slightly currently to improve what happens
> the next time you use your machine substantially. Because it changes with the
> amount of application pages in ram, it will not increasingly sacrifice
> performance when your memory is full with application pages. What it will not
> do is improve the swap thrash situation when you have grossly overloaded your
> ram.
>
> Con
My box rocks with you patch Con ! Swappiness is floating between 50->65.
I never saw a 2.6 box so quick in rl5.
Thanks !
FabF
On Wed, 02 Jun 2004 13:50:42 +1000, Tim Connors said:
> I do often get frustrated that the DoS card is brought up to kill a
> potentially useful solution. I think there should be a flag in KConfig
> saying "This machine will be a server"/"This machine will be mostly a
> single user desktop machine". In the latter, you can enable all these
> vm/etc heuristics that will help out mozilla/X/your favourite
> bloat-ware, but potentially enable a DoS attack, and in the former,
> you stay conservative.
And with that, you've worried about whether it's a potential DoS or
not. I didn't bring it up to "kill" it - I brought it up to start a discussion,
because I felt that including that sort of feature without at least thinking
about the DoS issues was a bad idea. Shipping it with a Kconfig or
sysctl flag, or using the capabilities framework, or any other similar
"allow the sysadmin to control it" feature is a different matter entirely...
On Wed, 02 Jun 2004 01:17:06 +0200, Bernd Eckenfels <[email protected]> said:
> Yes but: your wm is so often used/activated it will not get swaped out.
> But if your mouse passes over mozilla and tries to focus it, then you will
> feel the pain of a swapped-out x program.
Yes, I'm quite familiar with what a swapped-out mozilla does to my laptop ;)
The point I was making (apparently poorly) was that if mozilla is swapping in,
*that window* is hosed, but if the WM or the X server is swapping in,
*everything* is hosed.
And I *have* had times when I've left for an extended period while Mozilla
is downloading a Knoppix .iso or similar beastly large thing, and it managed
to keep Mozilla pages hot because it was busy doing a download, and the WM
pages got swapped out because the WM wasn't actually doing anything...
Yes, it's a rare state of affairs, but it *has* happened...
On Wed, 02 Jun 2004 07:38:41 +0200, FabF said:
> > Yes but: your wm is so often used/activated it will not get swaped out.
> > But if your mouse passes over mozilla and tries to focus it, then you will
> > feel the pain of a swapped-out x program.
> >
> Exactly !
> Does autoregulated VM swap. patch could help here ?
Con's auto-adjusting swappiness patch did in fact help that quite a bit,
especially for the case of heavy file I/O causing process images to be swapped
out. I need to do some comparisons of that to Nick's MM work...
On Wed, 2004-06-02 at 19:59, [email protected] wrote:
> On Wed, 02 Jun 2004 07:38:41 +0200, FabF said:
>
> > > Yes but: your wm is so often used/activated it will not get swaped out.
> > > But if your mouse passes over mozilla and tries to focus it, then you will
> > > feel the pain of a swapped-out x program.
> > >
> > Exactly !
> > Does autoregulated VM swap. patch could help here ?
>
> Con's auto-adjusting swappiness patch did in fact help that quite a bit,
> especially for the case of heavy file I/O causing process images to be swapped
> out. I need to do some comparisons of that to Nick's MM work...
It helps inactive applications to re-ermerge smoothly, heavy I/O and
global tuning.I've got 20 swapping delta from start to high usage.
That patch rock'n'roll my box until updatedb makes sw climbs up to 80
and freezes my box :(
FabF
On Thu, 3 Jun 2004 04:30, FabF wrote:
> On Wed, 2004-06-02 at 19:59, [email protected] wrote:
> > On Wed, 02 Jun 2004 07:38:41 +0200, FabF said:
> > > > Yes but: your wm is so often used/activated it will not get swaped
> > > > out. But if your mouse passes over mozilla and tries to focus it,
> > > > then you will feel the pain of a swapped-out x program.
> > >
> > > Exactly !
> > > Does autoregulated VM swap. patch could help here ?
> >
> > Con's auto-adjusting swappiness patch did in fact help that quite a bit,
> > especially for the case of heavy file I/O causing process images to be
> > swapped out. I need to do some comparisons of that to Nick's MM work...
>
> It helps inactive applications to re-ermerge smoothly, heavy I/O and
> global tuning.I've got 20 swapping delta from start to high usage.
> That patch rock'n'roll my box until updatedb makes sw climbs up to 80
> and freezes my box :(
Try this version instead which biases it downwards.
Con
FabF wrote:
> As I said, I think this thread is "becoming offtopic" but what can be
> interesting is the swapping problem fragmentation :
>
> 1.Global inactivity (what you're talking about)
> 2.Application isolation (what we're talking about).
>
> Geek or not, someone backgrounding an application doesn't want it to
> down the box for X seconds some minutes later when it comes back and
> such things arrive many times a day.Maybe you've got an idea about a
> better rule(s) then ? (I mean for the 2 cases)
Maybe what we need is a per-process tuner like nice, for swap candidacy.
Unfortunately doing it right is probably 2.7 material, you want users to
be able to set it DOWN for seldom used things, but not UP where they
could hog the system. And I think 'right' also means having a capability
for setting it UP again, etc.
Note that there are some hooks which *might* be useful for quick user,
there is a sticky bit which seems pretty unused in practice, and which
might cause pages to be marked less likely to swap. You could implement
in exec() to do the setting, with whatever access control seems useful.
Just a thought, I'm pretty well convinced that Nick's latest patches
have reduced the problem, at least for me. I'll try to get some metrics
on the measured effect, but the "feel" is better by far.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Con Kolivas wrote:
> On Wed, 2 Jun 2004 15:38, FabF wrote:
>
>>On Wed, 2004-06-02 at 01:17, Bernd Eckenfels wrote:
>>
>>>In article <[email protected]> you
>
> wrote:
>
>>>>out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
>>>>disk after extended inactivity - but if my window manager gets swapped
>>>>out, I get peeved when focus-follows-mouse doesn't and my typing goes
>>>>into the wrong window or some such... ;)
>>>
>>>Yes but: your wm is so often used/activated it will not get swaped out.
>>>But if your mouse passes over mozilla and tries to focus it, then you
>>>will feel the pain of a swapped-out x program.
>>
>>Exactly !
>>Does autoregulated VM swap. patch could help here ?
>
>
> Unless you are pushing the limits of your available ram by your usage pattern
> then yes the autoregulated swappiness patch should help.
>
> available here:
> http://ck.kolivas.org/patches/2.6/2.6.7-rc2/patch-2.6.7-rc2-am11
>
> Just a brief word that might clarify things for people. It seems this huge
> swap discussion centres around 2 different arguments. Akpm has said that the
> correct way for the vm to behave is that of swappiness=100. Desktop users
> note they have less swap out of the programs they use with swappiness 0 or
> their swap turned off. When your swappiness is set high, the current vm
> decisions are the fastest they can be, but when you go back to your
> applications they will take longer to restart. When your swappiness is set
> low your applications will restart rapidly, but the current vm will be doing
> more work and be slower. Most benchmarks will show the latter, but most
> desktop users will feel the former and not really notice the latter.
>
> Try the little experiment to see: Boot with mem=128M and try to compile a 2.6
> kernel with all the debugging symbols option enabled - do this with
> swappiness set to 0 and then at 100. You'll see it compile much faster at
> 100. Yet you know that if you set your swappiness to 0 mozilla will load
> faster next time you use it on your desktop during your normal usage pattern
> (of course you'd probably be using mozilla on a system with a bit more than
> 128M ram but this helps demonstrate the point).
>
> Does this explain in coarse examples to the desktop users why ideal systems
> shouldn't be swap disabled or swappiness=0 ?
>
> The autoregulated swappiness patch tries to get some sort of common ground,
> where it sacrifices performance slightly currently to improve what happens
> the next time you use your machine substantially. Because it changes with the
> amount of application pages in ram, it will not increasingly sacrifice
> performance when your memory is full with application pages. What it will not
> do is improve the swap thrash situation when you have grossly overloaded your
> ram.
But swap behaviour kills performance even when memory is more than
adequate. Consider building a DVD image in a 4GB system. The i/o forces
all of the unused programs out, in spite of the fact that an extra 100MB
doesn't make a measurable difference in performance. But when I click
Mozilla paging most of it in from disk make a big difference in
performance to the user.
My perception is that the system is really bad at recognizing
diminishing returns to be had by paging programs for the benefit of i/o.
Not to mention what happens if you get 2-3GB of dirty buffers and then
do a sync(). In practice my little RAID array will take at most 40MB/s,
so the creation of a DVD runs fast, but the system bogs right after.
The problems with small memory are different in kind, when not even the
programs will fit in memory at the same time, or will leave next to
nothing for i/o, swap is required for performance. But on a large memory
system I believe the gain to pain ratio is way too low with the current
VM. The solution at the moment is to turn off swap, which as you note
has other problems (can't move between zones without swap?) which in
theory could really hang a system.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
[email protected] wrote:
> On Wed, 02 Jun 2004 07:38:41 +0200, FabF said:
>
>
>>>Yes but: your wm is so often used/activated it will not get swaped out.
>>>But if your mouse passes over mozilla and tries to focus it, then you will
>>>feel the pain of a swapped-out x program.
>>>
>>
>>Exactly !
>>Does autoregulated VM swap. patch could help here ?
>
>
> Con's auto-adjusting swappiness patch did in fact help that quite a bit,
> especially for the case of heavy file I/O causing process images to be swapped
> out. I need to do some comparisons of that to Nick's MM work...
I haven't had a chance to try Con's stuff, the Nick patch is working
VERY well for me, small memory and slow system, lots of memory pressure.
Hopefully you can report a comparison.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Fri, 4 Jun 2004 00:18, Bill Davidsen wrote:
> [email protected] wrote:
> > On Wed, 02 Jun 2004 07:38:41 +0200, FabF said:
> >>>Yes but: your wm is so often used/activated it will not get swaped
> >>> out. But if your mouse passes over mozilla and tries to focus it, then
> >>> you will feel the pain of a swapped-out x program.
> >>
> >>Exactly !
> >>Does autoregulated VM swap. patch could help here ?
> >
> > Con's auto-adjusting swappiness patch did in fact help that quite a bit,
> > especially for the case of heavy file I/O causing process images to be
> > swapped out. I need to do some comparisons of that to Nick's MM work...
>
> I haven't had a chance to try Con's stuff, the Nick patch is working
> VERY well for me, small memory and slow system, lots of memory pressure.
> Hopefully you can report a comparison.
Well note there are two revisions available now. The original linear design is
here:
http://ck.kolivas.org/patches/2.6/2.6.7-rc2/patch-2.6.7-rc2-am11
and there is an exponential curve bias in this one which will probably
deprecate the last one:
http://ck.kolivas.org/patches/2.6/2.6.7-rc2/patch-2.6.7-rc2-as
I am keen to get more feedback; apart from what I get off list there has been
very little in the way of reports.
Con
On Thu, 2004-06-03 at 01:54, Con Kolivas wrote:
> On Thu, 3 Jun 2004 04:30, FabF wrote:
> > On Wed, 2004-06-02 at 19:59, [email protected] wrote:
> > > On Wed, 02 Jun 2004 07:38:41 +0200, FabF said:
> > > > > Yes but: your wm is so often used/activated it will not get swaped
> > > > > out. But if your mouse passes over mozilla and tries to focus it,
> > > > > then you will feel the pain of a swapped-out x program.
> > > >
> > > > Exactly !
> > > > Does autoregulated VM swap. patch could help here ?
> > >
> > > Con's auto-adjusting swappiness patch did in fact help that quite a bit,
> > > especially for the case of heavy file I/O causing process images to be
> > > swapped out. I need to do some comparisons of that to Nick's MM work...
> >
> > It helps inactive applications to re-ermerge smoothly, heavy I/O and
> > global tuning.I've got 20 swapping delta from start to high usage.
> > That patch rock'n'roll my box until updatedb makes sw climbs up to 80
> > and freezes my box :(
>
> Try this version instead which biases it downwards.
>
> Con
>
> ______________________________________________________________________
> diff -Naurp --exclude-from=dontdiff linux-2.6.7-rc2-base/include/linux/swap.h linux-2.6.7-rc2-am11/include/linux/swap.h
> --- linux-2.6.7-rc2-base/include/linux/swap.h 2004-05-31 21:29:21.000000000 +1000
> +++ linux-2.6.7-rc2-am11/include/linux/swap.h 2004-05-31 23:39:26.020055153 +1000
> @@ -175,6 +175,7 @@ extern void swap_setup(void);
> extern int try_to_free_pages(struct zone **, unsigned int, unsigned int);
> extern int shrink_all_memory(int);
> extern int vm_swappiness;
> +extern int auto_swappiness;
>
> #ifdef CONFIG_MMU
> /* linux/mm/shmem.c */
> diff -Naurp --exclude-from=dontdiff linux-2.6.7-rc2-base/include/linux/sysctl.h linux-2.6.7-rc2-am11/include/linux/sysctl.h
> --- linux-2.6.7-rc2-base/include/linux/sysctl.h 2004-05-31 21:29:21.000000000 +1000
> +++ linux-2.6.7-rc2-am11/include/linux/sysctl.h 2004-05-31 23:39:26.021054997 +1000
> @@ -164,6 +164,7 @@ enum
> VM_LAPTOP_MODE=23, /* vm laptop mode */
> VM_BLOCK_DUMP=24, /* block dump mode */
> VM_HUGETLB_GROUP=25, /* permitted hugetlb group */
> + VM_AUTO_SWAPPINESS=26, /* Make vm_swappiness autoregulated */
> };
>
>
> diff -Naurp --exclude-from=dontdiff linux-2.6.7-rc2-base/kernel/sysctl.c linux-2.6.7-rc2-am11/kernel/sysctl.c
> --- linux-2.6.7-rc2-base/kernel/sysctl.c 2004-05-31 21:29:24.000000000 +1000
> +++ linux-2.6.7-rc2-am11/kernel/sysctl.c 2004-05-31 23:40:57.658756170 +1000
> @@ -727,6 +727,14 @@ static ctl_table vm_table[] = {
> .extra1 = &zero,
> .extra2 = &one_hundred,
> },
> + {
> + .ctl_name = VM_AUTO_SWAPPINESS,
> + .procname = "autoswappiness",
> + .data = &auto_swappiness,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = &proc_dointvec,
> + },
> #ifdef CONFIG_HUGETLB_PAGE
> {
> .ctl_name = VM_HUGETLB_PAGES,
> diff -Naurp --exclude-from=dontdiff linux-2.6.7-rc2-base/mm/vmscan.c linux-2.6.7-rc2-am11/mm/vmscan.c
> --- linux-2.6.7-rc2-base/mm/vmscan.c 2004-05-31 21:29:24.000000000 +1000
> +++ linux-2.6.7-rc2-am11/mm/vmscan.c 2004-05-31 23:39:26.051050316 +1000
> @@ -43,6 +43,7 @@
> * From 0 .. 100. Higher means more swappy.
> */
> int vm_swappiness = 60;
> +int auto_swappiness = 1;
> static long total_memory;
>
> #define lru_to_page(_head) (list_entry((_head)->prev, struct page, lru))
> @@ -634,6 +635,41 @@ refill_inactive_zone(struct zone *zone,
> */
> mapped_ratio = (ps->nr_mapped * 100) / total_memory;
>
> + if (auto_swappiness) {
> +#ifdef CONFIG_SWAP
> + int app_percent;
> + struct sysinfo i;
> +
> + si_swapinfo(&i);
> +
> + if (likely(i.totalswap >= 100)) {
> + int swap_centile;
> +
> + /*
> + * app_percent is the percentage of physical ram used
> + * by application pages.
> + */
> + si_meminfo(&i);
> + app_percent = 100 - ((i.freeram + get_page_cache_size() -
> + swapper_space.nrpages) / (i.totalram / 100));
> +
> + /*
> + * swap_centile is the percentage of the last (sizeof physical
> + * ram) of swap free.
> + */
> + swap_centile = i.freeswap /
> + (min(i.totalswap, i.totalram) / 100);
> + /*
> + * Autoregulate vm_swappiness to be equal to the lowest of
> + * app_percent and swap_centile. Bias it downwards -ck
> + */
> + vm_swappiness = min(app_percent, swap_centile);
> + vm_swappiness = vm_swappiness * vm_swappiness / 100;
> + } else
> + vm_swappiness = 0;
> +#endif
> + }
> +
> /*
> * Now decide how much we really want to unmap some pages. The mapped
> * ratio is downgraded - just because there's a lot of mapped memory
I've been unhappy with this one.sw range : 19->60.
So I've been playing slightly with sw curve replacing nerve centre with
:
vm_swappiness = vm_swappiness * vm_swappiness / 50;
if (vm_swappiness > 100)
vm_swappiness = 100;
Results :
Warmup :Smooth, 30
Under pressure, swap grows roughly 60*60/50->72, 70*70/50->98 .... and
... rock'n'roll .... Box seems to keep the road this time.
updatedb gives side effects after 30 sec. though....sw drops to 70 ...
but I've got good global response.I guess we could expose curve
parameter.That one seems determinant :
vm_swappiness = vm_swappiness * vm_swappiness / swapcurve;
if (vm_swappiness > 100)
vm_swappiness = 100;
and sysctl stuff as well :
{
.ctl_name = VM_AUTO_SWAPPINESS,
.procname = "swapcurvature",
.data = &swapcurve,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = &proc_curvature,
},
Regards,
FabF
On Fri, 4 Jun 2004 02:16, FabF wrote:
> On Thu, 2004-06-03 at 01:54, Con Kolivas wrote:
> > Try this version instead which biases it downwards.
> I've been unhappy with this one.sw range : 19->60.
> So I've been playing slightly with sw curve replacing nerve centre with
Are you unhappy with the numbers for swappiness it gives or the feel of it? It
gives a range of 0-100 in meaningful ways. Your version gives swappiness >
100 at times (oops). If this version does not feel good, the last linear one
is better and you simply dont have enough ram for it to feel good after
updatedb.
Con
Bill Davidsen wrote:
> Just a thought, I'm pretty well convinced that Nick's latest patches
> have reduced the problem, at least for me. I'll try to get some metrics
> on the measured effect, but the "feel" is better by far.
>
Well thanks for testing them. I have another version with
minor bug fixes and a sync up to recent -mm changes.
http://www.kerneltrap.org/~npiggin/nickvm-267r2m2.gz
On Fri, 4 Jun 2004 09:56, Con Kolivas wrote:
> On Fri, 4 Jun 2004 02:16, FabF wrote:
> > On Thu, 2004-06-03 at 01:54, Con Kolivas wrote:
> > > Try this version instead which biases it downwards.
> >
> > I've been unhappy with this one.sw range : 19->60.
> > So I've been playing slightly with sw curve replacing nerve centre with
>
> Are you unhappy with the numbers for swappiness it gives or the feel of it?
> It gives a range of 0-100 in meaningful ways. Your version gives swappiness
> > 100 at times (oops). If this version does not feel good, the last linear
> one is better and you simply dont have enough ram for it to feel good after
> updatedb.
Oh and I forgot to say, if that's the case then you should try Nick's patches
which are far more sophisticated than this.
Con
> But swap behaviour kills performance even when memory is more than
> adequate. Consider building a DVD image in a 4GB system. The i/o forces
> all of the unused programs out, in spite of the fact that an extra 100MB
> doesn't make a measurable difference in performance. But when I click
> Mozilla paging most of it in from disk make a big difference in
> performance to the user.
We really need a server option. Something that ages out file backed pages
naturally with less overhead than kswapd. One method would be to keep the
pagecache on it's own list, and move pages to the head of the list any time
they are modified or referenced, and reclaim from the tail.
All pages on this list can be considered as "free memory", because any new
memory requests would just cause pages to be evicted from the tail of the
list.
Anonymous memory would *not* be on this list. This way any time anonymous
memory is allocated, the pages can be readily stolen from the pagecache
list.
Lastly one nifty configuration parameter that could exist as a knob for
sys-admins is the ability to tell the VM not to add file backed pages with
the execute bit set to the page cache list but rather, leave them to be
reclaimed if kswapd wakes up in a true low memory situation (pagecache is
exhausted and memory is still low). This would require a sys-admin to make
sure only executables have the execute bit set and "data files", etc... do
not have the execute bit set.
A system that works like this is nice for the following reasons:
1) The system administrator can size a system so that all programs
Safely run within physical RAM. Extra RAM
Could be added and sized based on the need
for caching files.
2) Anonymous pages (and possibly executable if you read
the last paragraph above) will only be evicted if kswapd is
awaken due to a true memory shortage (1/128th pagable memory?).
I like to view the VM system as always being full, because if enough unique
file system IO takes place, that is exactly what eventually happens. A
system that counts page cache as free memory and uses a gentler mechanism to
evict pages from the page cache would benefit IO bound servers significantly
IMHO.
--Buddy
Hello!
> But swap behaviour kills performance even when memory is more than adequate.
> Consider building a DVD image in a 4GB system. The i/o forces all of the
> unused programs out, in spite of the fact that an extra 100MB doesn't make a
> measurable difference in performance. But when I click Mozilla paging most of
> it in from disk make a big difference in performance to the user.
I think that kernel cannot know that you need some data once or more.
This is fadvise for.
With my wrapper (http://kernel.umbrella.ro) for fadvise you can do this:
NOCA_SIZE=128 NOCA_READ=1 NOCA_WRITE=1 NOCA_RA=1 \
noca mkisofs -R -o /tmp/1.iso /tmp/data
This means:
NOCA_SIZE: Call fadvise only after 128KiB was read/wrote.
NOCA_RA: call fadvise with POSIX_FADV_SEQUENTIAL
NOCA_READ: use fadvise(POSIX_FADV_DONTNEED) for reads (because you don't
need anymore the source files)
NOCA_WRITE: use fadvise(POSIX_FADV_DONTNEED) for writes (because it's
useless to cache the end of the ISO)
Do this program resolve your problem?
> The problems with small memory are different in kind, when not even the
> programs will fit in memory at the same time, or will leave next to nothing
> for i/o, swap is required for performance. But on a large memory system I
> believe the gain to pain ratio is way too low with the current VM. The
> solution at the moment is to turn off swap, which as you note has other
> problems (can't move between zones without swap?) which in theory could
> really hang a system.
>
> --
> -bill davidsen ([email protected])
> "The secret to procrastination is to put things off until the
> last possible moment - but no longer" -me
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
Buddy Lumpkin wrote:
>>But swap behaviour kills performance even when memory is more than
>>adequate. Consider building a DVD image in a 4GB system. The i/o forces
>>all of the unused programs out, in spite of the fact that an extra 100MB
>>doesn't make a measurable difference in performance. But when I click
>>Mozilla paging most of it in from disk make a big difference in
>>performance to the user.
>
>
>
> We really need a server option. Something that ages out file backed pages
> naturally with less overhead than kswapd. One method would be to keep the
> pagecache on it's own list, and move pages to the head of the list any time
> they are modified or referenced, and reclaim from the tail.
>
> All pages on this list can be considered as "free memory", because any new
> memory requests would just cause pages to be evicted from the tail of the
> list.
>
> Anonymous memory would *not* be on this list. This way any time anonymous
> memory is allocated, the pages can be readily stolen from the pagecache
> list.
>
> Lastly one nifty configuration parameter that could exist as a knob for
> sys-admins is the ability to tell the VM not to add file backed pages with
> the execute bit set to the page cache list but rather, leave them to be
> reclaimed if kswapd wakes up in a true low memory situation (pagecache is
> exhausted and memory is still low). This would require a sys-admin to make
> sure only executables have the execute bit set and "data files", etc... do
> not have the execute bit set.
Or have the exec() call set a "part of a process" flag. That means that
if I read an executable in as data it doesn't get locked, other than
what part might be in my i/o buffers. And mmap can produce different
effects than read/write which may be good, if they are GOOD different
effects ;-) Before you ask, thing 'strings' as why avg user does this.
But I fail to make my point... I want to limit how much memory is used
for i/o buffers, cache, or anything else which will produce memory
pressure of my programs. The quick solution might be just a number from
the admin, like the 2.2 patch, but some kernel logic to understand that
while 20MB is much better than 10MB in a tiny system, 2GB is not a lot
better than 1GB in a large memory system, and having a sync() bog the
system for tens of seconds is undesirable. Well, maybe some folks don't
agree, it could be that the admin set limit is really the way to go.
I regard this as a desktop issue, trading some i/o performance to keep
window changes fast.
>
>
> A system that works like this is nice for the following reasons:
>
> 1) The system administrator can size a system so that all programs
> Safely run within physical RAM. Extra RAM
> Could be added and sized based on the need
> for caching files.
>
> 2) Anonymous pages (and possibly executable if you read
> the last paragraph above) will only be evicted if kswapd is
> awaken due to a true memory shortage (1/128th pagable memory?).
>
>
> I like to view the VM system as always being full, because if enough unique
> file system IO takes place, that is exactly what eventually happens. A
> system that counts page cache as free memory and uses a gentler mechanism to
> evict pages from the page cache would benefit IO bound servers significantly
> IMHO.
That's what would be nice with tuning, the admin can optimize what is
important on that system. I am usually happy with what the system does
on i/o, but I want my 500MB or so of programs to stay resident in a 2GB
machine, and if that adds a ms or two to i/o I can live with it, so that
when I change windows it happens now, not eventually. And I bet there
are a lot of others who would like better response to focus changes aswell.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Catalin BOIE wrote:
> Hello!
>
>> But swap behaviour kills performance even when memory is more than
>> adequate. Consider building a DVD image in a 4GB system. The i/o
>> forces all of the unused programs out, in spite of the fact that an
>> extra 100MB doesn't make a measurable difference in performance. But
>> when I click Mozilla paging most of it in from disk make a big
>> difference in performance to the user.
>
>
> I think that kernel cannot know that you need some data once or more.
> This is fadvise for.
> With my wrapper (http://kernel.umbrella.ro) for fadvise you can do this:
> NOCA_SIZE=128 NOCA_READ=1 NOCA_WRITE=1 NOCA_RA=1 \
> noca mkisofs -R -o /tmp/1.iso /tmp/data
>
> This means:
> NOCA_SIZE: Call fadvise only after 128KiB was read/wrote.
> NOCA_RA: call fadvise with POSIX_FADV_SEQUENTIAL
> NOCA_READ: use fadvise(POSIX_FADV_DONTNEED) for reads (because you don't
> need anymore the source files)
> NOCA_WRITE: use fadvise(POSIX_FADV_DONTNEED) for writes (because it's
> useless to cache the end of the ISO)
>
> Do this program resolve your problem?
It addresses one of the cases which trigger problems, certainly. Thank you.
>
>> The problems with small memory are different in kind, when not even
>> the programs will fit in memory at the same time, or will leave next
>> to nothing for i/o, swap is required for performance. But on a large
>> memory system I believe the gain to pain ratio is way too low with the
>> current VM. The solution at the moment is to turn off swap, which as
>> you note has other problems (can't move between zones without swap?)
>> which in theory could really hang a system.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Thu, 3 Jun 2004, Bill Davidsen wrote:
> My perception is that the system is really bad at recognizing
> diminishing returns to be had by paging programs for the benefit of i/o.
Currently the kernel has no mechanisms at all to do any
kind of detection of bad pageout decisions it made in
the past, and consequently no way to learn for the future.
Checks and balances ... those are what's missing ;)
--
"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
Fri, 04 Jun 2004 @ 13:08 -0400, Bill Davidsen said:
> But I fail to make my point... I want to limit how much memory is used
> for i/o buffers, cache, or anything else which will produce memory
> pressure of my programs.
I would love to be able to limit this kind of memory use.
I've always liked how BSD works in this area, never using over a certain
amount.
I find the Linux behavior of using all memory for things like
buffercache is less than optimal. While there are situations where it
helps, there are a great many where it hurts.
I frequently do work which fills memory with data I'll never use again,
and it makes things slow.
Desktop work tends to do this kind of thing as well.
> That's what would be nice with tuning, the admin can optimize what is
> important on that system. I am usually happy with what the system does
> on i/o, but I want my 500MB or so of programs to stay resident in a 2GB
> machine, and if that adds a ms or two to i/o I can live with it, so that
> when I change windows it happens now, not eventually. And I bet there
> are a lot of others who would like better response to focus changes aswell.
Not only that, but I wish certain bits of code could be locked into
memory. Generally any code and data associated with the user interface
should always be there.
It's annoying when a menu in X takes ten seconds of swapping to appear.
--
shannon "AT" widomaker.com -- [javalin: an unwieldy programming weapon used
to stab a software project through the heart until dead]