Matthew Woehlke wrote:
Colin Walters wrote:
Ok, I only skimmed his article initially, I thought his argument was
basically that it's better for interactivity to have a smaller buffer
cache than to (preemptively or not) page out application sections (be
that text, or stack/heap).
The down-side, of course, is that less buffering will slow down
whatever is trying to do I/O, which can cause the very responsiveness
issues you're trying to fix.
Certainly in the default configuration, the heap can be paged out, no?
I think by "Prioritize code." he really means "whatever the app needs
to respond to user input".
I think the default configuration is to reserve 40% of memory for
buffering, and the rest for application memory (there is a kernel
parameter to tune it, I forget what though).
Hmm... will quantum memory allow to store both buffer AND app memory
in ram, such that the system will choose which is actually read
(thereby "destroying" the other)? Because that's what we really
need... otherwise you don't know if it's better to keep that file you
just read, or the app memory that hasn't been touched in 30 minutes.
If you just read in a .cpp in a mass build (say, something the size of
KDE), chances are you don't need it again... especially when the user
goes back to writing that letter he stopped working on 30 minutes ago.
Or maybe the user won't work on the letter and that file is the
database the user is currently working with. The point is, there isn't
a way to /know/, so the kernel has to just guess, and it favors (in
its current configuration) new things.
Though big picture if you're swapping very much you've basically lost.
Yes, but for someone like me, you need a HUGE amount of RAM to avoid
swapping. I build KDE and do digital photography. The former needs
probably a few GB of ram, at least (when you account for file
buffering, especially in massively-parallel builds). The latter also
needs a few GB of memory, especially if working on multiple images.
I'd say 16 GB is a good number, but not so many desktops have that
much (not yet at least). (Netbooks certainly don't, but then, you
probably shouldn't be doing that sort of workload on a netbook in the
first place.) Even hard-core web browsing can eat upwards of 1 GB
(lots of sites open, especially graphics-heavy ones).
IOW, planning how to swap /well/ is still important, IMO.
I may be totally "out in the weeds" with this comment, but here goes.
Is is possible to set up a small app that would maintain a record of the
swap/buffer usage patterns and set up a "sliding scale" that would move
the swap priority based on the usage pattern of the logged in user? I
say this because different people tend to use their computers in
different ways, as seen above. This would also allow a "starting point"
for system tuning based on the amount of RAM and paging ratios. In the
past I have had to do system tuning for Oracle DBs and know that
different DB architectures require different tuning. It is a very
technical art, generally beyond a nominal user. A usage tracking app
may go a long way toward "auto tuning" based on usage patterns of
particular users.
--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
