> On Mon, Oct 11, 2010 at 12:45:39PM +0400, Dmitry-T wrote: > > 11.10.10, 12:13, "Claudio Jeker" <[email protected]>: > > > > > You try to renice I/O bound > > > processes. The scheduler priority only matters when processes are CPU > > > bound. > > > > Yes of course, but... all my "dd" processes use CPU. > > After run "dd if=/dev/urandom of=/dev/null" > > first three "dd if=/dev/wd0c of=/dev/null bs=1m" reduce their part of CPU > > and > > run "renice" not recover their part of CPU. > > CPU consumed by the kernel is not accounted by the scheduler. All the > work done by urandom is system time.
Unlike many people who have replied, I think this is a real problem. The problem is that the in-kernel random code violates a promise that process-issued kernel code must make -- kernel code must as be efficient as possible for the operation that it is doing. In a unix system, we must strive to not add O(expensive) operations directly accessible via simple userland requests. Generally on the drivers since this means that the code is having to wait for an interrupt, or such. Ted just replaced /dev/random with arandom a few days ago, and this is much much more efficient. It looks like the problem is largely gone. And we get a better random number generator. More problems like this will exist, and when found they should be fixed through analysis, not reverse accusations on the mailing lists.
