Linus Torvalds wrote:
>
> ...
>
> I'll think about this some more. One thing I noticed is that the
> "wake_up(>wait);" at the end of __down() is kind of bogus: we don't
> actually want to wake anybody up at that point at all, it's just that if
> we don't wake anybody up we'll end up having "sem
Linus Torvalds wrote:
...
I'll think about this some more. One thing I noticed is that the
"wake_up(sem-wait);" at the end of __down() is kind of bogus: we don't
actually want to wake anybody up at that point at all, it's just that if
we don't wake anybody up we'll end up having "sem =
On Sun, 19 Nov 2000, Andrew Morton wrote:
>
> I don't see a path where David's patch can cause a lost wakeup in the
> way you describe.
Basically, if there are two up() calls, they might end up waking up only
one process, because the same process goes to sleep twice. That's wrong.
It should
Linus Torvalds wrote:
>
> ...
> But the algorithm itself should allow for other values. In fact, I think
> that you'll find that it works fine if you switch to non-exclusive
> wait-queues, and the only reason you see the repeatable D states is
> exactly the case where we didn't "take" the
Linus Torvalds wrote:
...
But the algorithm itself should allow for other values. In fact, I think
that you'll find that it works fine if you switch to non-exclusive
wait-queues, and the only reason you see the repeatable D states is
exactly the case where we didn't "take" the semaphore
On Sun, 19 Nov 2000, Andrew Morton wrote:
I don't see a path where David's patch can cause a lost wakeup in the
way you describe.
Basically, if there are two up() calls, they might end up waking up only
one process, because the same process goes to sleep twice. That's wrong.
It should wake
On Sun, 19 Nov 2000, Andrew Morton wrote:
>
> Has anyone tried it on SMP? I get fairly repeatable instances of immortal
> `D'-state processes with this patch.
Too bad. I really thought it should be safe to do.
> The patch isn't right - it allows `sleepers' to increase without bound.
> But
Christoph Rohland wrote:
>
> Hi David,
>
> David Mansfield <[EMAIL PROTECTED]> writes:
> > If you can find the time to check this out more completely, I recommend
> > it, because it seems like a great improvement to be able to accurately
> > see vmstat numbers in times of system load. I hope
Hi David,
David Mansfield <[EMAIL PROTECTED]> writes:
> If you can find the time to check this out more completely, I recommend
> it, because it seems like a great improvement to be able to accurately
> see vmstat numbers in times of system load. I hope the other side
> effects are beneficial
Hi David,
David Mansfield [EMAIL PROTECTED] writes:
If you can find the time to check this out more completely, I recommend
it, because it seems like a great improvement to be able to accurately
see vmstat numbers in times of system load. I hope the other side
effects are beneficial as well
Christoph Rohland wrote:
Hi David,
David Mansfield [EMAIL PROTECTED] writes:
If you can find the time to check this out more completely, I recommend
it, because it seems like a great improvement to be able to accurately
see vmstat numbers in times of system load. I hope the other
On Sun, 19 Nov 2000, Andrew Morton wrote:
Has anyone tried it on SMP? I get fairly repeatable instances of immortal
`D'-state processes with this patch.
Too bad. I really thought it should be safe to do.
The patch isn't right - it allows `sleepers' to increase without bound.
But it's a
Hi Linus et al,
I've applied your semaphore fairness patch (slightly fixed) below. It
fixes my original bug report of vmstat, ps etc. stalls waiting for the
mmap_sem. I can now run my memory 'hog' processes and actually see
vmstat update every second even under heavy memory pressure. More
Hi Linus et al,
I've applied your semaphore fairness patch (slightly fixed) below. It
fixes my original bug report of vmstat, ps etc. stalls waiting for the
mmap_sem. I can now run my memory 'hog' processes and actually see
vmstat update every second even under heavy memory pressure. More
14 matches
Mail list logo
