In article <[EMAIL PROTECTED]>,
David Mansfield <[EMAIL PROTECTED]> wrote:
>Linus Torvalds wrote:
>...
>>
>> And it has everything to do with the fact that the way Linux semaphores
>> are implemented, a non-blocking process has a HUGE advantage over a
>> blocking one. Linux kernel semaphores
Linus Torvalds wrote:
...
>
> And it has everything to do with the fact that the way Linux semaphores
> are implemented, a non-blocking process has a HUGE advantage over a
> blocking one. Linux kernel semaphores are extreme unfair in that way.
>
...
> The original running process comes back
In article <[EMAIL PROTECTED]>,
Mike Galbraith <[EMAIL PROTECTED]> wrote:
>>
>> (This schenario, btw, is much harder to trigger on SMP than on UP. And
>> it's completely separate from the issue of simple disk bandwidth issues
>> which can obviously cause no end of stalls on anything that needs
> I understood the above well enough to be very interested in seeing what
> happens with flush IO restricted.
>
> -Mike
>
> [try_to_free_pages()->swap_out()/shm_swap().. can fight over who gets
> to shrink the best candidate's footprint?]
>
> Thanks!
The results:
pre2+semaphore
real
On Thu, 9 Nov 2000, Linus Torvalds wrote:
>
>
> As to the real reason for stalls on /proc//stat, I bet it has nothing
> to do with IO except indirectly (the IO is necessary to trigger the
> problem, but the _reason_ for the problem lies elsewhere).
>
> And it has everything to do with the
As to the real reason for stalls on /proc//stat, I bet it has nothing
to do with IO except indirectly (the IO is necessary to trigger the
problem, but the _reason_ for the problem lies elsewhere).
And it has everything to do with the fact that the way Linux semaphores
are implemented, a
On Fri, 3 Nov 2000, Jens Axboe wrote:
> On Fri, Nov 03 2000, Mike Galbraith wrote:
> > > I very much agree. Kflushd is still hungry for free write
> > > bandwidth here.
> >
> > In the LKML tradition of code talks and silly opinions walk...
> >
> > Attached is a diagnostic patch which gets
On Fri, Nov 03 2000, Mike Galbraith wrote:
> > I very much agree. Kflushd is still hungry for free write
> > bandwidth here.
>
> In the LKML tradition of code talks and silly opinions walk...
>
> Attached is a diagnostic patch which gets kflushd under control,
> and takes make -j30 bzImage
On Fri, 3 Nov 2000, Mike Galbraith wrote:
> On Thu, 2 Nov 2000, Jens Axboe wrote:
>
> > On Thu, Nov 02 2000, Val Henson wrote:
> > > > > 3) combine this with the elevator starvation stuff (ask Jens
> > > > >Axboe for blk-7 to alleviate this issue) and you have a
> > > > >scenario where
On Thu, 2 Nov 2000, Jens Axboe wrote:
> On Thu, Nov 02 2000, Val Henson wrote:
> > > > 3) combine this with the elevator starvation stuff (ask Jens
> > > >Axboe for blk-7 to alleviate this issue) and you have a
> > > >scenario where processes using /proc//stat have the
> > > >
On Thu, Nov 02 2000, Val Henson wrote:
> > > 3) combine this with the elevator starvation stuff (ask Jens
> > >Axboe for blk-7 to alleviate this issue) and you have a
> > >scenario where processes using /proc//stat have the
> > >possibility to block on multiple processes that are in
On Thu, Nov 02, 2000 at 08:19:06AM +0100, Mike Galbraith wrote:
> On Wed, 1 Nov 2000, Rik van Riel wrote:
>
> > I have one possible reason for this
> >
> > 1) the procfs process does (in fs/proc/array.c::proc_pid_stat)
> > down(>mmap_sem);
> >
> > 2) but, in order to do that, it has
Hi Rik,
I can probably give some more datapoints. Here is the console output
of my test machine (there is a 'vmstat 5' running in background):
[root@ls3016 /root]# killall shmtst
[root@ls3016 /root]#
1 12 2 0 1607668 18932 2110496 0 0 67154 1115842 1050063 2029389 0 2
98
0 10
On Wed, 1 Nov 2000, Rik van Riel wrote:
> On Wed, 1 Nov 2000, David Mansfield wrote:
>
> > I'd like to report what seems like a performance problem in the latest
> > kernels. Actually, all recent kernels have exhibited this problem, but
> > I was waiting for the new VM stuff to stabilize
On Wed, 1 Nov 2000, David Mansfield wrote:
> I'd like to report what seems like a performance problem in the latest
> kernels. Actually, all recent kernels have exhibited this problem, but
> I was waiting for the new VM stuff to stabilize before reporting it.
>
> My test is: run 7 processes
Hi VM/procfs hackers,
System is UP Athlon 700mhz with 256mb ram running vanilla 2.4.0-test10.
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
I'd like to report what seems like a performance problem in the latest
kernels. Actually, all recent kernels have exhibited this problem,
16 matches
Mail list logo
