From: Daniel Phillips <phillips@istop.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: Sridhar Samudrala <sri@us.ibm.com>,
netdev@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Network vm deadlock... solution?
Date: Wed, 3 Aug 2005 09:04:27 +1000 [thread overview]
Message-ID: <200508030904.27711.phillips@istop.com> (raw)
In-Reply-To: <20050802214340.GA6309@electric-eye.fr.zoreil.com>
On Wednesday 03 August 2005 07:43, Francois Romieu wrote:
> Daniel Phillips <phillips@istop.com> :
> [...]
>
> > A point on memory pressure: here, we are not talking about the continuous
> > state of running under heavy load, but rather the microscopically short
> > periods where not a single page of memory is available to normal tasks.
> > It is when a block IO event happens to land inside one of those
> > microscopically short periods that we run into problems.
>
> You suggested in a previous message to use an emergency allocation pool at
> the driver level. Afaik, 1) the usual network driver can already buffer a
> bit with its Rx descriptor ring and 2) it more or less tries to refill it
> each time napi issues its ->poll() method. So it makes me wonder:
> - have you collected evidence that the drivers actually run out of memory
> in the (microscopical) situation you describe ?
Yes, e.g:
http://thunker.thunk.org/pipermail/ksummit-2005-discuss/2005-March/000200.html
and NBD is known to be unreliable for this reason. I plan to put together
a before-and-after test that everybody can try, but after I show the patch for
comment.
> - instead of modifying each and every driver to be vm aware, why don't
> you hook in net_rx_action() when memory starts to be low ?
Two reasons:
* The first handling has to be where the packet is allocated
* net_rx_action is on the far side of a queue, which would need to be
throttled separately. But the throttle would not know which packets to
discard, because the packet headers have not been examined yet.
> Btw I do not get what the mempool/GFP_CRITICAL idea buys: it seems
> redundant with the threshold ("if (memory_pressure)") used in the Rx path
> to decide that memory is low.
It is not to decide if memory is low, but to tell the vm system that it is
allowed to allocate from the reserve if normal memory is exhausted.
Regards,
Daniel.
--
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>
prev parent reply other threads:[~2005-08-02 23:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200508020654.32693.phillips@istop.com>
[not found] ` <1123003658.3754.28.camel@w-sridhar2.beaverton.ibm.com>
2005-08-02 20:13 ` Daniel Phillips
2005-08-02 21:43 ` Francois Romieu
2005-08-02 22:39 ` Martin J. Bligh
2005-08-03 0:55 ` Daniel Phillips
2005-08-02 23:04 ` Daniel Phillips [this message]
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=200508030904.27711.phillips@istop.com \
--to=phillips@istop.com \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
--cc=sri@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox