Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

My apologies...my internic data isn't updated, http://208.179.0.18/VM/

-d


--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: VM brokenness, possibly related to reiserfs

[Rik van Riel]

On Wed, 31 Jan 2001, David Ford wrote:

> The dumps are large so they are located at http://stuph.org/VM/.

I can't seem to resolve this domain ...

> Here's the story.  I boot and startx, I load xmms and netscape
> to eat away memory.  When free buffers/cache falls below 7M the
> system stalls and the only recovery is sysrq-E or reboot.  At
> the moment of stall the disk will grind continuously for about
> 25 to 30 minutes then go silent.  At this point in time the only
> recovery is reboot, sysrq-E won't work.

> Kernel 2.4.1, with reiserfs, devfs, no patches applied.

Between 2.4.0 and 2.4.1, a few VM changes were made by
Linus and Marcelo. These are good changes, but they seem
to need a little bit of tuning in related code to get
system behaviour right again.

I'm working on these changes and should have a (few)
rebalancing patches out soon to fix the performance
problem.

About the system hanging completely, I wonder if it goes
away by pressing sysrq-S (sync all disks). If it does,
maybe Reiserfs was blocking all the pages in the inactive
list from being written because one of the active pages
(not a replacement candidate) needed to be written out
first?  Or does the Reiserfs ->writepage() function handle
this?

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[Chris Mason]

On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel <riel@conectiva.com.br> wrote:

> 
> About the system hanging completely, I wonder if it goes
> away by pressing sysrq-S (sync all disks). If it does,
> maybe Reiserfs was blocking all the pages in the inactive
> list from being written because one of the active pages
> (not a replacement candidate) needed to be written out
> first?  Or does the Reiserfs ->writepage() function handle
> this?
> 

In most cases, the reiserfs writepage func is the same as block_write_full_page.  The only difference should come when a packed tail has been mmap'd.

Since JOURNAL_MAX_BATCH was at 100, the log should have only pinned 400k.  More blocks could be pinned, but kreiserfsd should be in the process of flushing those.

I've been trying out a few things to send memory pressure down to reiserfs, but they have mostly been based on the code to make fs/buffer.c use writepage for flushing.  I should have done something simple first, I'll start on that now.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

My apologies...my internic data isn't updated, http://208.179.0.18/VM/

-d


--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

Chris Mason wrote:

> 
> On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel <riel@conectiva.com.br> wrote:
> 
>> About the system hanging completely, I wonder if it goes
>> away by pressing sysrq-S (sync all disks). If it does,
>> maybe Reiserfs was blocking all the pages in the inactive
>> list from being written because one of the active pages
>> (not a replacement candidate) needed to be written out
>> first?  Or does the Reiserfs ->writepage() function handle
>> this?
> 

In answer to Rik's question, no, sysrq-S doesn't fix it.  The sound of 
the disk grind changes momentarily then it resumes.

> In most cases, the reiserfs writepage func is the same as block_write_full_page.  The only difference should come when a packed tail has been mmap'd.
> 
> Since JOURNAL_MAX_BATCH was at 100, the log should have only pinned 400k.  More blocks could be pinned, but kreiserfsd should be in the process of flushing those.
> 
> I've been trying out a few things to send memory pressure down to reiserfs, but they have mostly been based on the code to make fs/buffer.c use writepage for flushing.  I should have done something simple first, I'll start on that now.
> 
> -chris


http://stuph.org/VM/ is back up, no thanks to the network solutions.  
The files listed there have all the relevant backtraces.

-d


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: VM brokenness, possibly related to reiserfs

[Chris Mason]

On Wednesday, January 31, 2001 11:02:46 PM -0800 David Ford <david@linux.com> wrote:

> (Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect
> anything).
> 
> Ok, having approached this slightly more intelligently here are [better]
> results.
> 
> The dumps are large so they are located at http://stuph.org/VM/.  Here's
> the story.  

Sorry, can't seem to resolve stuph.org.  What is kreiserfsd doing during when the system is waiting for more ram?  With JOURNAL_MAX_BATCH set to 100, kreiserfsd will end up responsible for sending log blocks/metadata to disk and freeing the pinned buffers.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

Chris Mason wrote:

> Sorry, can't seem to resolve stuph.org.  What is kreiserfsd doing during when the system is waiting for more ram?  With JOURNAL_MAX_BATCH set to 100, kreiserfsd will end up responsible for sending log blocks/metadata to disk and freeing the pinned buffers.
>
> -chris

(http://208.179.0.18/VM/)

[schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [reiserfs_journal_commit_thread+173/224] [kernel_thread+40/56]

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/