> I just reproduced the problem in test10-pre7. Here's the
> output you requested:
>
> vmstat 1
> procs memoryswap io system cpu
> r b w swpd free buff cache si sobibo incs us sy id
> 0 2 2 0 45764
On Mon, Oct 30 2000, Miles Lane wrote:
> I just reproduced the problem in test10-pre7. Here's the
> output you requested:
Thanks
> vmstat 1
> procs memoryswap io system cpu
> r b w swpd free buff cache si sobibo incs
On Mon, Oct 30 2000, Miles Lane wrote:
I just reproduced the problem in test10-pre7. Here's the
output you requested:
Thanks
vmstat 1
procs memoryswap io system cpu
r b w swpd free buff cache si sobibo incs us
Jens Axboe wrote:
> On Sun, Oct 29 2000, Miles Lane wrote:
>
There were still some stalls but they only lasted a couple of
seconds. The patch did make a difference and for the better.
>>>
>>>
>>> Ok, still needs a bit of work. Thanks for the feedback.
>>
>> Have you resolved this
Jens Axboe wrote:
On Sun, Oct 29 2000, Miles Lane wrote:
There were still some stalls but they only lasted a couple of
seconds. The patch did make a difference and for the better.
Ok, still needs a bit of work. Thanks for the feedback.
Have you resolved this problem completely, now?
I am posting the completed NWFS 2.4.4 tommorrow, and it NEVER exhibits
this lockup problem on the console, no matter how busy the I/O subsystem
underneath becomes. I think this is probably because I use my own
elevator and LRU and don't use Linus's buffer cache. Whatever is
causing it I would
On Sun, Oct 29 2000, Miles Lane wrote:
> >> There were still some stalls but they only lasted a couple of
> >> seconds. The patch did make a difference and for the better.
> >
> >
> > Ok, still needs a bit of work. Thanks for the feedback.
>
> Have you resolved this problem completely, now?
>
Jens Axboe wrote:
> On Sat, Oct 28 2000, Rui Sousa wrote:
>
>> After adding
>>
>> #define ELEVATOR_HOLE_MERGE 3
>>
>> to linux/include/linux/elevator.h it compiled ok.
>
>
> Oops sorry, I'm on the road so the patch was extracted
> from my packet writing tree (and not my regular tree).
>
On Sun, Oct 29 2000, Miles Lane wrote:
There were still some stalls but they only lasted a couple of
seconds. The patch did make a difference and for the better.
Ok, still needs a bit of work. Thanks for the feedback.
Have you resolved this problem completely, now?
I am testing
I am posting the completed NWFS 2.4.4 tommorrow, and it NEVER exhibits
this lockup problem on the console, no matter how busy the I/O subsystem
underneath becomes. I think this is probably because I use my own
elevator and LRU and don't use Linus's buffer cache. Whatever is
causing it I would
On Sat, Oct 28 2000, Rui Sousa wrote:
> After adding
>
> #define ELEVATOR_HOLE_MERGE 3
>
> to linux/include/linux/elevator.h it compiled ok.
Oops sorry, I'm on the road so the patch was extracted
from my packet writing tree (and not my regular tree).
> There were still some stalls but
On Fri, 27 Oct 2000, Jens Axboe wrote:
...
> > So it seems the process is either in a loop in ___wait_on_page()
> > racing for the PageLock or it never wakes-up... (I guess I could add a
> > printk to check which)
> > Unfortunately I didn't find anything obviously wrong with the code.
> > I hope
On Fri, Oct 27 2000, Rui Sousa wrote:
> I finally had time to give this a better look. It now seems the problem
> is in the VM system.
>
> I patched a test10-pre4 kernel with kdb, then started two "diff -ur
> linux-2.4.0testX linux-2.4.0testY > log1" and two "find / -true >
> log". After this I
On Fri, 27 Oct 2000, Rui Sousa wrote:
> I finally had time to give this a better look. It now seems the
> problem is in the VM system.
*sigh*
> schedule()
> ___wait_on_page()
> do_generic_file_read()
> generic_file_read()
> sys_read()
> system_call()
>
> So it seems the process is either in a
On Sun, 8 Oct 2000, Rik van Riel wrote:
> On Sun, 8 Oct 2000, Rui Sousa wrote:
>
> > After starting 2 processes that scan a lot of files (diff, find,
> > slocate, ...) it's impossible to run any other processes that
> > touch the disk, they will stall until one of the first two stop.
> > Could
On Sun, 8 Oct 2000, Rik van Riel wrote:
On Sun, 8 Oct 2000, Rui Sousa wrote:
After starting 2 processes that scan a lot of files (diff, find,
slocate, ...) it's impossible to run any other processes that
touch the disk, they will stall until one of the first two stop.
Could this be a
On Fri, 27 Oct 2000, Rui Sousa wrote:
I finally had time to give this a better look. It now seems the
problem is in the VM system.
*sigh*
schedule()
___wait_on_page()
do_generic_file_read()
generic_file_read()
sys_read()
system_call()
So it seems the process is either in a loop in
On Fri, Oct 27 2000, Rui Sousa wrote:
I finally had time to give this a better look. It now seems the problem
is in the VM system.
I patched a test10-pre4 kernel with kdb, then started two "diff -ur
linux-2.4.0testX linux-2.4.0testY log1" and two "find / -true
log". After this I tried
On Fri, 27 Oct 2000, Jens Axboe wrote:
...
So it seems the process is either in a loop in ___wait_on_page()
racing for the PageLock or it never wakes-up... (I guess I could add a
printk to check which)
Unfortunately I didn't find anything obviously wrong with the code.
I hope you can
On Sat, Oct 28 2000, Rui Sousa wrote:
After adding
#define ELEVATOR_HOLE_MERGE 3
to linux/include/linux/elevator.h it compiled ok.
Oops sorry, I'm on the road so the patch was extracted
from my packet writing tree (and not my regular tree).
There were still some stalls but they only
On Sun, 8 Oct 2000, Rik van Riel wrote:
> On Sun, 8 Oct 2000, Rui Sousa wrote:
>
> > After starting 2 processes that scan a lot of files (diff, find,
> > slocate, ...) it's impossible to run any other processes that
> > touch the disk, they will stall until one of the first two stop.
> > Could
On Sun, 8 Oct 2000, Rik van Riel wrote:
On Sun, 8 Oct 2000, Rui Sousa wrote:
After starting 2 processes that scan a lot of files (diff, find,
slocate, ...) it's impossible to run any other processes that
touch the disk, they will stall until one of the first two stop.
Could this be a
On Sun, 8 Oct 2000, Rui Sousa wrote:
> After starting 2 processes that scan a lot of files (diff, find,
> slocate, ...) it's impossible to run any other processes that
> touch the disk, they will stall until one of the first two stop.
> Could this be a sign of starvation in the elevator code?
Hi,
I reported this problem before but didn't get any answers so I'm posting
again.
After starting 2 processes that scan a lot of files (diff, find,
slocate, ...) it's impossible to run any other processes that touch
the disk, they will stall until one of the first two stop. Could this be
a
Hi,
I reported this problem before but didn't get any answers so I'm posting
again.
After starting 2 processes that scan a lot of files (diff, find,
slocate, ...) it's impossible to run any other processes that touch
the disk, they will stall until one of the first two stop. Could this be
a
On Sun, 8 Oct 2000, Rui Sousa wrote:
After starting 2 processes that scan a lot of files (diff, find,
slocate, ...) it's impossible to run any other processes that
touch the disk, they will stall until one of the first two stop.
Could this be a sign of starvation in the elevator code?
It
26 matches
Mail list logo
