From: Daniel Phillips <phillips@bonn-fries.net>
To: Marcelo Tosatti <marcelo@conectiva.com.br>,
Mike Galbraith <mikeg@wen-online.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.4.5-ac15
Date: Thu, 21 Jun 2001 15:14:31 +0200 [thread overview]
Message-ID: <01062115143101.00374@starship> (raw)
In-Reply-To: <Pine.LNX.4.21.0106210226330.14247-100000@freak.distro.conectiva>
In-Reply-To: <Pine.LNX.4.21.0106210226330.14247-100000@freak.distro.conectiva>
On Thursday 21 June 2001 07:44, Marcelo Tosatti wrote:
> On Thu, 21 Jun 2001, Mike Galbraith wrote:
> > On Thu, 21 Jun 2001, Marcelo Tosatti wrote:
> > > Ok, I suspect that GFP_BUFFER allocations are fucking up here (they
> > > can't block on IO, so they loop insanely).
> >
> > Why doesn't the VM hang the syncing of queued IO on these guys via
> > wait_event or such instead of trying to just let the allocation fail?
>
> Actually the VM should limit the amount of data being queued for _all_
> kind of allocations.
>
> The problem is the lack of a mechanism which allows us to account the
> approximated amount of queued IO by the VM. (except for swap pages)
Coincidence - that's what I started working on two days ago, and I'm moving
into the second generation design today. Look at 'queued_sectors'. I found
pretty quickly it's not enough, today I'm adding 'submitted_sectors' to the
soup. This will allow me to distinguish between traffic generated by my own
thread and other traffic.
> > Does failing the allocation in fact accomplish more than what I'm
> > (uhoh:) assuming?
>
> No.
>
> It sucks really badly.
Amen.
--
Daniel
next prev parent reply other threads:[~2001-06-21 13:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-15 22:06 Linux 2.4.5-ac15 Alan Cox
2001-06-16 16:48 ` Tom Vier
2001-06-17 18:11 ` Walter Hofmann
2001-06-19 9:19 ` Walter Hofmann
2001-06-20 19:25 ` Adam Sampson
2001-06-19 21:23 ` Walter Hofmann
2001-06-20 19:56 ` Rik van Riel
2001-06-21 15:22 ` Walter Hofmann
2001-06-21 4:35 ` Marcelo Tosatti
2001-06-21 6:56 ` Mike Galbraith
2001-06-21 5:44 ` Marcelo Tosatti
2001-06-21 8:10 ` Mike Galbraith
2001-06-21 13:14 ` Daniel Phillips [this message]
2001-06-21 19:50 ` Marcelo Tosatti
2001-06-22 0:32 ` Daniel Phillips
2001-06-22 9:06 ` Mike Galbraith
2001-06-22 9:57 ` Marcelo Tosatti
2001-06-22 11:50 ` Mike Galbraith
2001-06-22 14:08 ` Linux 2.4.5-ac15 / 2.4.6-pre5 Walter Hofmann
2001-06-22 15:50 ` Mike Galbraith
2001-06-22 17:27 ` Walter Hofmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01062115143101.00374@starship \
--to=phillips@bonn-fries.net \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=mikeg@wen-online.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).