[lkml]   [2001]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)

    On Sun, 28 Jan 2001, Jens Axboe wrote:

    > On Sat, Jan 27 2001, Linus Torvalds wrote:
    > > > What was the trace of this? Just curious, the below case outlined by
    > > > Linus should be pretty generic, but I'd still like to know what
    > > > can lead to this condition.
    > >
    > > It was posted on linux-kernel - I don't save the dang things because I
    > > have too much in my "archives" as is ;)
    > Ok I see it now, confused wrt the different threads...
    > > > Good spotting. Actually I see one more problem with it too. If
    > > > we've started batching (under heavy I/O of course), we could
    > > > splice the pending list and wake up X number of sleepers, but
    > > > there's a) no guarentee that these sleepers will actually get
    > > > the requests if new ones keep flooding in
    > >
    > > (a) is ok. They'll go back to sleep - it's a loop waiting for requests..
    > My point is not that it's broken, but it will favor new comers
    > instead of tasks having blocked on a free slot already. So it
    > would still be nice to get right.
    > > > and b) no guarentee
    > > > that X sleepers require X request slots.
    > >
    > > Well, IF they are sleeping (and thus, if the wake_up_nr() will trigger on
    > > them), they _will_ use a request. I don't think we have to worry about
    > > that. At most we will wake up "too many" - we'll wake up processes even
    > > though they end up not being able to get a request anyway because somebody
    > > else got to it first. And that's ok. It's the "wake up too few" that
    > > causes trouble, and I think that will be fixed by my suggestion.
    > Yes they may end up sleeing right away again as per the above a) case
    > for instance. The logic now is 'we have X free slots now, wake up
    > x sleepers' where it instead should be 'we have X free slots now,
    > wake up people until the free list is exhausted'.
    > > Now, I'd worred if somebody wants several requests at the same time, and
    > > doesn't feed them to the IO layer until it has gotten all of them. In that
    > > case, you can get starvation with many people having "reserved" their
    > > requests, and there not be enough free requests around to actually ever
    > > wake anybody up again. But the regular IO paths do not do this: they will
    > > all allocate a request and just submit it immediately, no "reservation".
    > Right, the I/O path doesn't do this and it would seem more appropriate
    > to have such users use their own requests instead of eating from
    > the internal pool.
    > --
    > * Jens Axboe <>
    > * SuSE Labs
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > Please read the FAQ at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:24    [W:0.024 / U:2.200 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site