All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: Indan Zupancic <indan@nul.nu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	Daniel Phillips <phillips@google.com>,
	Rik van Riel <riel@redhat.com>,
	David Miller <davem@davemloft.net>
Subject: [RFC][PATCH 0/4] VM deadlock prevention -v4
Date: Sat, 12 Aug 2006 16:14:15 +0200	[thread overview]
Message-ID: <20060812141415.30842.78695.sendpatchset@lappy> (raw)

Hi,

here the latest effort, it includes a whole new trivial allocator with a
horrid name and an almost full rewrite of the deadlock prevention core.
This version does not do anything per device and hence does not depend 
on the new netdev_alloc_skb() API.

The reason to add a second allocator to the receive side is twofold:
1) it allows easy detection of the memory pressure / OOM situation;
2) it allows the receive path to be unbounded and go at full speed when
   resources permit.

The choice of using the global memalloc reserve as a mempool makes that
the new allocator has to release pages as soon as possible; if we were
to hoard pages in the allocator the memalloc reserve would not get 
replenished readily.

Peter

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: Indan Zupancic <indan@nul.nu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	Daniel Phillips <phillips@google.com>,
	Rik van Riel <riel@redhat.com>,
	David Miller <davem@davemloft.net>
Subject: [RFC][PATCH 0/4] VM deadlock prevention -v4
Date: Sat, 12 Aug 2006 16:14:15 +0200	[thread overview]
Message-ID: <20060812141415.30842.78695.sendpatchset@lappy> (raw)

Hi,

here the latest effort, it includes a whole new trivial allocator with a
horrid name and an almost full rewrite of the deadlock prevention core.
This version does not do anything per device and hence does not depend 
on the new netdev_alloc_skb() API.

The reason to add a second allocator to the receive side is twofold:
1) it allows easy detection of the memory pressure / OOM situation;
2) it allows the receive path to be unbounded and go at full speed when
   resources permit.

The choice of using the global memalloc reserve as a mempool makes that
the new allocator has to release pages as soon as possible; if we were
to hoard pages in the allocator the memalloc reserve would not get 
replenished readily.

Peter

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2006-08-12 14:15 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-12 14:14 Peter Zijlstra [this message]
2006-08-12 14:14 ` [RFC][PATCH 0/4] VM deadlock prevention -v4 Peter Zijlstra
2006-08-12 14:14 ` [RFC][PATCH 1/4] pfn_to_kaddr() for UML Peter Zijlstra
2006-08-12 14:14   ` Peter Zijlstra
2006-08-12 14:14 ` [RFC][PATCH 2/4] SROG allocator Peter Zijlstra
2006-08-12 14:14   ` Peter Zijlstra
2006-08-12 14:14 ` [RFC][PATCH 3/4] deadlock prevention core Peter Zijlstra
2006-08-12 14:14   ` Peter Zijlstra
2006-08-12 14:41   ` Jeff Garzik
2006-08-12 14:41     ` Jeff Garzik
2006-08-12 15:06     ` rename *MEMALLOC flags (was: Re: [RFC][PATCH 3/4] deadlock prevention core) Peter Zijlstra
2006-08-12 15:06       ` Peter Zijlstra
2006-08-12 15:28       ` Indan Zupancic
2006-08-12 15:28         ` Indan Zupancic
2006-08-12 15:28         ` Indan Zupancic
2006-08-12 15:34         ` Peter Zijlstra
2006-08-12 15:34           ` Peter Zijlstra
2006-08-12 15:34           ` Peter Zijlstra
2006-08-14  0:06       ` rename *MEMALLOC flags Daniel Phillips
2006-08-14  0:06         ` Daniel Phillips
2006-08-14  1:00         ` Paul Jackson
2006-08-14  1:00           ` Paul Jackson
2006-08-14  3:42           ` Nick Piggin
2006-08-14  3:42             ` Nick Piggin
2006-08-12 17:31   ` [RFC][PATCH 3/4] deadlock prevention core Indan Zupancic
2006-08-12 17:31     ` Indan Zupancic
2006-08-12 17:44     ` Peter Zijlstra
2006-08-12 17:44       ` Peter Zijlstra
2006-08-12 17:54       ` Indan Zupancic
2006-08-12 17:54         ` Indan Zupancic
2006-08-12 18:08         ` Peter Zijlstra
2006-08-12 18:08           ` Peter Zijlstra
2006-08-12 18:32           ` Indan Zupancic
2006-08-12 18:32             ` Indan Zupancic
2006-08-12 18:47             ` Peter Zijlstra
2006-08-12 18:47               ` Peter Zijlstra
2006-08-12 19:45               ` Indan Zupancic
2006-08-12 19:45                 ` Indan Zupancic
2006-08-12 14:14 ` [RFC][PATCH 4/4] deadlock prevention for NBD Peter Zijlstra
2006-08-12 14:14   ` Peter Zijlstra
2006-08-24 14:43   ` Pavel Machek
2006-08-24 14:43     ` Pavel Machek
2006-08-12 16:51 ` [RFC][PATCH 0/4] VM deadlock prevention -v4 Indan Zupancic
2006-08-12 16:51   ` Indan Zupancic
2006-08-12 17:33   ` Peter Zijlstra
2006-08-12 17:33     ` Peter Zijlstra
2006-08-12 18:16     ` Indan Zupancic
2006-08-12 18:16       ` Indan Zupancic
2006-08-12 18:54       ` Peter Zijlstra
2006-08-12 18:54         ` Peter Zijlstra
2006-08-12 20:05         ` Indan Zupancic
2006-08-12 20:05           ` Indan Zupancic
2006-08-14  0:42         ` Daniel Phillips
2006-08-14  0:42           ` Daniel Phillips
2006-08-14  5:20           ` Evgeniy Polyakov
2006-08-14  5:20             ` Evgeniy Polyakov
2006-08-14 12:21             ` Rik van Riel
2006-08-14 12:21               ` Rik van Riel
2006-08-14 12:51               ` Herbert Xu
2006-08-14 12:51                 ` Herbert Xu
2006-08-14 14:22                 ` Rik van Riel
2006-08-14 14:22                   ` Rik van Riel

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=20060812141415.30842.78695.sendpatchset@lappy \
    --to=a.p.zijlstra@chello.nl \
    --cc=davem@davemloft.net \
    --cc=indan@nul.nu \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=netdev@vger.kernel.org \
    --cc=phillips@google.com \
    --cc=riel@redhat.com \
    /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.