Re: 2.6.17-rc4-mm3

[Valdis.Kletnieks@vt.edu]

On Mon, 22 May 2006 13:49:28 +0200, Michael Buesch said:

> Andrew's comment on this:
> 
> 	What's going on with the need_resched() tricks in there?  (Unobvious, needs
> 	a comment).  From my reading, it'll cause a caller to this function to hang
> 	for arbitrary periods of time if something if causing heavy scheduling
> 	pressure.
> 
> So I decided to remove it and return -EAGAIN, so userspace can retry.
> But seems like it it does not. I thought glibc would handle that.

On the other hand, the *old* code did the same 'need_resched()' test - although
it was slightly different:

               if(need_resched())
                        schedule_timeout_interruptible(1);
                else
                        udelay(200);    /* FIXME: We could poll for 250uS ?? */ 

I tossed the else because we have the poll loop elsewhere (the only delay in
the old code was that udelay).

And it's probably no *great* sin if it blocks for a long time - remember that
we're waiting for more entropy to show up.  And if we don't resched, we basically
end up spinning until we get all the entropy we want.

Note that the current userspace will go and snarf up 2500 (yes, 2500) bytes
of data, and then spend the next half hour or so feeding it into /dev/random
in small chunks once a minute.  At least on my laptop, strace reports the
read as taking 0.46 seconds.  I'm pretty sure we want to resched once in
a while, rather than lock up a CPU for half a second. :)

Attachment: pgp5lucH62S9r.pgp
Description: PGP signature