All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.