FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Desktop

 
 
LinkBack Thread Tools
 
Old 02-17-2009, 07:40 PM
Adam Jackson
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

On Tue, 2009-02-17 at 20:19 +0100, Valent Turkovic wrote:
> http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
>
> What is you comment?

If we really thought this was true, it would be straightforward enough
to bump the mlock limits for users and get some of the high-touch apps
to lock their text sections. I can add this to the X server tomorrow
trivially even without that (the joys of being root).

I'm not _that_ convinced. I mean, the way to measure this is to look at
the io trace hooks and see what you end up reading in. I'd be mildly
surprised if it was text sections.

- ajax
--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 02-17-2009, 08:57 PM
Adam Jackson
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

On Tue, 2009-02-17 at 16:15 -0500, 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).
>
> 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".
>
> This is apparently not a new debate: http://kerneltrap.org/node/3000
>
> Though big picture if you're swapping very much you've basically lost.
> So the biggest wins here definitely involve fixing applications (like
> federico's work on image caching and jemalloc in Firefox, alex's
> recent blog about tracking down extra nautilus heap usage).

There have been a couple of other ideas along these lines that I've been
kicking around for a while. I'm not taking credit, certainly these
aren't revolutionary, but I do think they'd be worthwhile.

* Memory pressure signal from the kernel. If the kernel gets within
(say) 5% of needing to evict something from memory to satisfy an
allocation, it could mark some fd readable, and then apps could
voluntarily shrink their caches. If the time to recreate from source is
less than the cost of swapping, this wins; think JPEG to pixmap
expansion cost here.

* Casual pixmaps in X. Normally we have to hold on to pixel data come
hell or high water. Firefox could reasonably create its pixmaps through
some other channel if it knew that it had the source data still to work
with; this would give X the ability to respond to the above pressure
signal sanely.

* Compressed image transport in X. We did have this at one point but it
wasn't a big performance win in terms of raw drawing speed. But for
memory pressure? Maybe worth it.

- ajax
--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 02-17-2009, 09:20 PM
Matthew Woehlke
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

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.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
If a signature
is not read by anyone,
does it make a sound?

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 02-17-2009, 09:59 PM
Roy Bynum
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 02-17-2009, 11:11 PM
Matthew Woehlke
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

Roy Bynum wrote:
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?


Good question. I don't know enough if it can track usage patterns, but
my guess is it could. (At least, if running as root; if not root I think
it could only read the memory of processes belonging to the effective
user, but since you say it should track that users' stuff anyway I think
that's a non-issue. That said...) AFAIK the ratio is adjustable in
real-time. (...it might need to be root to tweak the ratio, or else have
an suid helper program. The latter is probably better... although it's
probably better to make the whole thing run as root so it is
system-wide. For single-user systems, it will mostly track the logged-in
user anyway, but also account for system daemons. For multi-user
systems, presumably you don't want to treat one user preferentially. And
surely you don't want multiple instances running and contending on what
to make the ratio.)


Short answer: I think it's possible.

Usage patterns are a function of user /and time/. I assume such a
program could be tuned to handle varying usage patterns as well.


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
If a signature
is not read by anyone,
does it make a sound?

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 02-18-2009, 03:39 AM
Roy Bynum
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

Matthew Woehlke wrote:

Roy Bynum wrote:
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?


Good question. I don't know enough if it can track usage patterns, but
my guess is it could. (At least, if running as root; if not root I
think it could only read the memory of processes belonging to the
effective user, but since you say it should track that users' stuff
anyway I think that's a non-issue. That said...) AFAIK the ratio is
adjustable in real-time. (...it might need to be root to tweak the
ratio, or else have an suid helper program. The latter is probably
better... although it's probably better to make the whole thing run as
root so it is system-wide. For single-user systems, it will mostly
track the logged-in user anyway, but also account for system daemons.
For multi-user systems, presumably you don't want to treat one user
preferentially. And surely you don't want multiple instances running
and contending on what to make the ratio.)


Short answer: I think it's possible.

Usage patterns are a function of user /and time/. I assume such a
program could be tuned to handle varying usage patterns as well.


Desktop systems tend to be single user and usage centric which can
change, while multiuser systems tend to be setup for a dedicated usage
which does not change. The tuning application would be optional in both
cases with at least two different modes of operation. The single user
would more likely use it in a transparent auto-tuning mode while the
administrator of the multiuser system would use it as a support tool in
non auto-tuning, reporting only mode.

One of the things that I have learned over the years is that what I
don't know exceeds what I do know. I may know the utilization that I
have for my systems and those that I have supported. There are probably
quite a few that I don't know about. If the single user systems were
given the option of sending feedback to a development repository and
provide a "usefulness" reporting site for feedback that could be used
for making adjustments to the auto-tuning parameters. In addition to
the nominal testing that would be done during development, other usage
and utilization functionalities can be accounted for.

This type of applications would be useful for a broad range of
implementations, and perhaps help reduce some of the "art" to system
tuning. Additionally, it might have a positive impact on "perceived"
desktop performance over a broad range of environments.


--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 02-18-2009, 03:37 PM
Matthew Woehlke
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

Roy Bynum wrote:

Desktop systems tend to be single user


This seems to be changing, in my experience. Linux especially encourages
multiple users.


My home system deals with two non-daemon users on a regular basis and
occasionally three... and I'm the only human using it. Family computers
will sometimes (and should /always/, TBH*) have different user accounts
for each family member.


(* not just for security reasons, it's also practical; each user gets
their own personalizations)


and usage centric which can
change, while multiuser systems tend to be setup for a dedicated usage
which does not change.


You clearly haven't met some of the systems I use, that get used for
anything and everything :-)... running IDE's, builds, stress testing...
Even a "single-purpose" box for software QA can easily run the gamut of
usage patterns.


The tuning application would be optional in both
cases with at least two different modes of operation. The single user
would more likely use it in a transparent auto-tuning mode while the
administrator of the multiuser system would use it as a support tool in
non auto-tuning, reporting only mode.


Sure, but if it's well-written, I don't see why you shouldn't be able to
use it to auto-tune on a multi-user system. Even on a "true" single-use
system, you could use it as a "fire and forget" way to improve
performance; I agree you probably will not get the maximum benefit from
this, but unless the program really sucks, it should be better than
leaving the default settings.


At any rate, my previous point was mainly that it should be able to
monitor the entire system (which likely requires elevated privileges).
Since you mentioned monitoring at the system-level, we seem to agree on
this.


One of the things that I have learned over the years is that what I
don't know exceeds what I do know. I may know the utilization that I
have for my systems and those that I have supported. There are probably
quite a few that I don't know about. If the single user systems were
given the option of sending feedback to a development repository and
provide a "usefulness" reporting site for feedback that could be used
for making adjustments to the auto-tuning parameters.


That sounds like an interesting idea.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Nobody expects the traditional Bourne shell!"

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
 
Old 02-20-2009, 04:36 PM
Alex de Jong
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

That's why I switched to FluxBox. Damn ugly, but fast.
I don't need the fancy blinking windows, sliding menu's or whatever,
But I see your problem: things like BlackBox tend to get too
ugly/unhandy fast...


Valent Turkovic wrote:

On Tue, Feb 17, 2009 at 8:19 PM, Valent Turkovic
<valent.turkovic@gmail.com> wrote:


http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that

What is you comment?

--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic




As a long time Linux desktop user and Linux enthusiast I want bloody
screaming fast desktop There are some situations that I just want
to pull my hair out when I see that desktop performance just crawls to
a halt

When I read articles like Tales from responsivenessland[1] I really
don't get why there aren't bells ringing in the heads of the people
who can actually make a difference for Linux desktop performance.

I was also really sad when I read interview with Con Kolivas[2] and
the reasons why he quit kernel development[3].

I hope kernel developers will wake up and realise that there are also
us - Desktop users and what we need and want are responsive desktops.

Will Fedora be the first Linux distro to have sane desktop defaults
(vm.swappiness=1 and vm.vfs_cache_pressure=50). Current Fedora slogan
is "Features. Freedom. Friends. First", I hope to see "Desktop
performance" as part of it soon

[1] http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
[2] http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_bor ing.htm
[3] http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm




--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-20-2009, 08:12 PM
Tom Horsley
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

> How about a new app: "system-config-performance"?

Or maybe system-config-sanity would be better :-).

There are so many schizophrenic conflicts in linux, it would
be nice to tame them all in one place.

Things like:

This thread talks about how the VM tuning seems to be for enterprise
use, yet at the same time the new default NetworkManager system
only works on laptops flitting about from one Starbucks to another.

The "prelinker" is enabled by default because one group of
geeks want their shared libs to load 10 nanoseconds faster
(while using 45 hours of cpu in a cron job to achieve that),
meanwhile the security geeks enable address space randomization
by default, thus insuring that everything the prelinker does
will be for naught because none of the libs will ever load
at the prelinked address.

And those are just off the top of my head - I'm sure there is
lots more insanity out there.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-20-2009, 11:32 PM
Bill Davidsen
 
Default Linux users want better desktop performance (Screw data. Prioritize code)

Valent Turkovic wrote:

On Tue, Feb 17, 2009 at 8:19 PM, Valent Turkovic
<valent.turkovic@gmail.com> wrote:

http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that

What is you comment?

--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



As a long time Linux desktop user and Linux enthusiast I want bloody
screaming fast desktop There are some situations that I just want
to pull my hair out when I see that desktop performance just crawls to
a halt

When I read articles like Tales from responsivenessland[1] I really
don't get why there aren't bells ringing in the heads of the people
who can actually make a difference for Linux desktop performance.

I was also really sad when I read interview with Con Kolivas[2] and
the reasons why he quit kernel development[3].

I've known Kon for years, sent him patches for his 2.4 based "ck" kernel
patches. But if you didn't read the LKML before he left, and can't follow the
code, you see his point of view without context.



I hope kernel developers will wake up and realise that there are also
us - Desktop users and what we need and want are responsive desktops.

Will Fedora be the first Linux distro to have sane desktop defaults
(vm.swappiness=1 and vm.vfs_cache_pressure=50). Current Fedora slogan
is "Features. Freedom. Friends. First", I hope to see "Desktop
performance" as part of it soon

I read that [3] article and the first two things I noticed were the reference to
"small RAM" which in the days of $11/GB RAM is rare, and that the author didn't
touch the "dirty" tuning parameters, which are better suited to controlling the
behavior of i/o buffers. He didn't mention tuning read ahead to speed reading of
application off the disk (which limits response even if lots of memory is
free). In short the article is based on one trick, not a balanced approach to
getting both responsive performance and good i/o performance.


I regularly handle images 4x the size of memory, and in 33 days uptime have
written a total of 109MB (from iostat) to swap. A balanced tune is far nicer
than cranking swappiness as low as it will go and keeping crap in memory which
is not needed (left over initialization code, error messages you never see, etc).



[1] http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
[2] http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_bor ing.htm
[3] http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm




--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 

Thread Tools




All times are GMT. The time now is 08:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org