public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed Sweetman <ed.sweetman@wmich.edu>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Con Kolivas <conman@kolivas.net>, linux-kernel@vger.kernel.org
Subject: Re: Benchmarks for performance patches (-ck) for 2.4.19
Date: Mon, 02 Sep 2002 00:00:39 -0400	[thread overview]
Message-ID: <3D72E267.6090502@wmich.edu> (raw)
In-Reply-To: Pine.LNX.4.44L.0209012327360.1857-100000@imladris.surriel.com

Rik van Riel wrote:
> On Sun, 1 Sep 2002, Ed Sweetman wrote:
> 
> 
>>Wouldn't the majority (to an undeniable extent) of the "responsiveness"
>>of desktop usage be on X's code? if we are talking about that.  The
>>problem with finding a benchmark is that first you have to have a
>>definition of what you're benchmarking.  The "system responsiveness"
>>term is far too vague. When there's a definition to the term there can
>>be a benchmark made to measure it.
> 
> 
> Agreed. Things like system responsiveness are fairly complex
> though and in many cases the average numbers measured by
> benchmarks don't mean anything to users.
> 
> I wish we had a way to measure this stuff, but I'll happily
> philosophise with you guys until we come up with a useful
> definition of something we could measure...
> 
> 
>>I mean, besides making the kernel with as low latency as possible, what
>>is bad about the responsiveness in the kernel?  If there's any lag in
>>responsiveness that i see it's always something X related, particularly
>>Xfree86.
> 
> 
> "low latency" != responsiveness
> 
> Any latency which is below the point the user can notice
> is effectively zero, so whether the 10000 wakeups/minute
> that the user doesn't notice are 2ms or 5ms don't really
> matter.

true.  But the latency that's N low multiplied by many processes can 
equal latencies that are in the range users can notice in a single app 
that maybe getting bullied by the others.  Lowering latencies cant be a 
bad thing unless they create unelegent code or introduce bugs.  That's 
all i meant by mentioning latency.

> What does matter are the wakeups that make the user's
> mp3 skip, even if these don't influence the statistics
> at all because there's only 1 every few minutes, or none,
> if the VM is balanced right ;)
> 
> Another responsiveness thing is how fast you can swap in
> Mozilla when the user comes in in the morning. More of a
> throughput than a latency thing in this case ... but you
> still have to make sure the mp3 doesn't skip while mozilla
> is being loaded.

Maybe i'm weird then because I've never had that happen.  The only time 
i've had my mp3s skip is when i purposely did things that would do that 
(saturate via bonnie or dbench).  I can see this occuring during 
swapping when dma is not used, but this just adds to the fact that it's 
no easy matter to define the problem.

> regards,
> 
> Rik

I dont experience audio cutouts with anything i do, even the really 
abusive things to the computer.  I've only had it cut out when using 
bonnie or dbench and that's something you should expect. So what i see 
as responsiveness is switching windows on the same desktop and switching 
between virtual desktops.  I see responsiveness as the time between i do 
something and the time it takes to redraw it. Using a G450, I expect a 
certain level of hardware performance and half a second or so to redraw 
a screen is not what i call responsive for a Tbird system. This is of 
course all X related because i dont see much or any problem with the 
console and with the kernel. At least nothing compared to X latencies.

the common user wants to see desktop performance equal to mac osX and 
windows and they come to linux which uses X and dont see that.  The 
problem is Xfree86 is a crossplatform network oriented windowing system 
and you get the same argument with it that people have with gcc.  The 
purpose of xfree86 and gcc is kind of the same and not the same as these 
other propriatary systems / compilers such as OSX or icc.  It's tough 
luck for us all but this is something that the xpert mailing list could 
better handle since what we're looking for is a tool that measures the 
performance of X under real workloads and where problem areas are.

Both the kernel and the programs used are involved when talking "system 
responsiveness" but in this case i think the kernel has been fine tuned 
much more strictly and thoroughly than xfree86 has.  I'd like to know if 
that's due to lack of man/woman power or if they're being restricted by 
compliance to aspects of X that maybe need to change as use has changed.


  reply	other threads:[~2002-09-02  3:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-02  1:10 Benchmarks for performance patches (-ck) for 2.4.19 Con Kolivas
2002-09-02  2:03 ` Ed Sweetman
2002-09-02  2:32   ` Rik van Riel
2002-09-02  4:00     ` Ed Sweetman [this message]
2002-09-02  7:39       ` Ingo Oeser
2002-09-02 13:20         ` Rik van Riel
2002-09-03  3:16         ` jw schultz
2002-09-02  5:22     ` Paul
2002-09-02  5:40       ` J Sloan
2002-09-02  5:57       ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2002-09-02  3:24 Dieter Nützel
2002-09-02  3:41 ` Rik van Riel
2002-09-02  3:42 ` Con Kolivas
2002-09-02  4:21   ` Randy.Dunlap
2002-09-02  9:12 Con Kolivas
2002-09-04  3:39 ` Paul
2002-09-02 12:50 Martin Knoblauch
2002-09-04  5:15 Wade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D72E267.6090502@wmich.edu \
    --to=ed.sweetman@wmich.edu \
    --cc=conman@kolivas.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox