lkml.org 
[lkml]   [2010]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/13] IO-less dirty throttling v2
On Thu, 18 Nov 2010 14:21:41 +1100 Dave Chinner <david@fromorbit.com> wrote:

> > But mainly because we're taking the work accounting away from the user
> > who caused it and crediting it to the kernel thread instead, and that's
> > an actively *bad* thing to do.
>
> The current foreground writeback is doing work on behalf of the
> system (i.e. doing background writeback) and therefore crediting it
> to the user process. That seems wrong to me; it's hiding the
> overhead of system tasks in user processes.
>
> IMO, time spent doing background writeback should not be creditted
> to user processes - writeback caching is a function of the OS and
> it's overhead should be accounted as such.

bah, that's bunk. Using this logic, _no_ time spent in the kernel
should be accounted to the user process and we may as well do away with
system-time accounting altogether.

If userspace performs some action which causes the kernel to consume
CPU resources, that consumption should be accounted to that process.

Yes, writeback can be inaccurate because process A will write back
process B's stuff, but that should even out on average, and it's more
accurate than saying "zero".

> Indeed, nobody has
> realised (until now) just how inefficient it really is because of
> the fact that the overhead is mostly hidden in user process system
> time.

"hidden"? You do "time dd" and look at the output!

_now_ it's hidden. You do "time dd" and whee, no system time! You
need to do complex gymnastics with kernel thread accounting to work out
the real cost of your dd.


\
 
 \ /
  Last update: 2010-11-18 04:41    [W:0.876 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site