On Thu, 18 Nov 2010 14:21:41 +1100 Dave Chinner <david@xxxxxxxxxxxxx> 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>