On 11/13/2012 05:54, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote:
On 11/12/2012 3:48 PM, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote:
This patch still doesn't address the issue of M_NOWAIT calls driving
the
On Thu, Nov 15, 2012 at 11:32:18AM -0600, Alan Cox wrote:
On 11/13/2012 05:54, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote:
On 11/12/2012 3:48 PM, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote:
This patch
On 11/15/2012 12:21, Konstantin Belousov wrote:
On Thu, Nov 15, 2012 at 11:32:18AM -0600, Alan Cox wrote:
On 11/13/2012 05:54, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote:
On 11/12/2012 3:48 PM, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at
On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote:
On 11/12/2012 3:48 PM, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote:
This patch still doesn't address the issue of M_NOWAIT calls driving
the memory the all the way down to 2 pages, right ?
On 11/12/2012 11:35, Alan Cox wrote:
On 11/12/2012 07:36, Konstantin Belousov wrote:
On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
kostik...@gmail.comwrote:
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
I
Hey, great catch!
adrian
On 13 November 2012 12:04, Alan Cox a...@rice.edu wrote:
On 11/12/2012 11:35, Alan Cox wrote:
On 11/12/2012 07:36, Konstantin Belousov wrote:
On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
On 11 November 2012 20:24, Alfred Perlstein bri...@mu.org wrote:
I think very few of the m_nowaits actually need the reserve behavior. We
should probably switch away from it digging that deep by default and
introduce a flag and/or a per thread flag to set the behavior.
There's already a
On 11.11.2012 22:40, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov kostik...@gmail.comwrote:
Your analysis is right, there is nothing to add or correct.
This is the reason to strongly prefer M_WAITOK.
Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It
On 12.11.2012 03:02, Adrian Chadd wrote:
On 11 November 2012 13:40, Alan Cox alan.l@gmail.com wrote:
Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was
well understand that it should only be used by interrupt handlers.
The trouble is that M_NOWAIT conflates two
On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
kostik...@gmail.comwrote:
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
I have a memory subsystem design question that I'm hoping someone can
answer.
On Mon, Nov 12, 2012 at 03:36:38PM +0200, Konstantin Belousov wrote:
On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
kostik...@gmail.comwrote:
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
I have a
On Mon, 2012-11-12 at 13:18 +0100, Andre Oppermann wrote:
Well, what's the current set of best practices for allocating mbufs?
If an allocation is driven by user space then you can use M_WAITOK.
If an allocation is driven by the driver or kernel (callout and so on)
you do M_NOWAIT and
On 12.11.2012 15:47, Ian Lepore wrote:
On Mon, 2012-11-12 at 13:18 +0100, Andre Oppermann wrote:
Well, what's the current set of best practices for allocating mbufs?
If an allocation is driven by user space then you can use M_WAITOK.
If an allocation is driven by the driver or kernel
On 11/12/2012 07:36, Konstantin Belousov wrote:
On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
kostik...@gmail.comwrote:
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
I have a memory subsystem design question
On Nov 12, 2012, at 4:11 AM, Andre Oppermann an...@freebsd.org wrote:
I don't think many places depend on M_NOWAIT digging deep. I'm
perfectly happy with having M_NOWAIT give up on first try. Only
together with M_TRY_REALLY_HARD it would dig into reserves.
PS: We have a really nasty
On Mon, Nov 12, 2012 at 11:35:42AM -0600, Alan Cox wrote:
Agreed. Most recently I eliminated several uses from the arm pmap
implementations. There is, however, one other use:
ofed/include/linux/gfp.h:#defineGFP_ATOMIC (M_NOWAIT |
M_USE_RESERVE)
Yes, I forgot to mention this. I
...@gmail.com wrote:
From: Konstantin Belousov kostik...@gmail.com
Subject: Re: Memory reserves or lack thereof
To: a...@freebsd.org
Cc: p...@freebsd.org, Sears, Steven steven.se...@netapp.com,
freebsd-hackers@freebsd.org freebsd-hackers@freebsd.org
Date: Monday, November 12, 2012, 5:36 AM
On Sun
On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote:
This patch still doesn't address the issue of M_NOWAIT calls driving
the memory the all the way down to 2 pages, right ? It would be nice to
have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE
flag to dig deep.
On 11/12/2012 3:48 PM, Konstantin Belousov wrote:
On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote:
This patch still doesn't address the issue of M_NOWAIT calls driving
the memory the all the way down to 2 pages, right ? It would be nice to
have M_NOWAIT just do non-sleep version of
.. wait, so what exactly would the difference be between M_NOWAIT and M_WAITOK?
adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
On 11/12/2012 5:24 PM, Adrian Chadd wrote:
.. wait, so what exactly would the difference be between M_NOWAIT and M_WAITOK?
Whether or not the allocation can sleep until memory becomes available.
___
freebsd-hackers@freebsd.org mailing list
On 12 November 2012 15:26, Alan Cox a...@rice.edu wrote:
On 11/12/2012 5:24 PM, Adrian Chadd wrote:
.. wait, so what exactly would the difference be between M_NOWAIT and
M_WAITOK?
Whether or not the allocation can sleep until memory becomes available.
Ok, so we're still maintaining that
--- On Mon, 11/12/12, Alan Cox a...@rice.edu wrote:
From: Alan Cox a...@rice.edu
Subject: Re: Memory reserves or lack thereof
To: Konstantin Belousov kostik...@gmail.com
Cc: Sushanth Rai sushanth_...@yahoo.com, a...@freebsd.org,
p...@freebsd.org, StevenSears steven.se...@netapp.com
On 11/12/12 3:49 PM, Adrian Chadd wrote:
On 12 November 2012 15:26, Alan Cox a...@rice.edu wrote:
On 11/12/2012 5:24 PM, Adrian Chadd wrote:
.. wait, so what exactly would the difference be between M_NOWAIT and
M_WAITOK?
Whether or not the allocation can sleep until memory becomes available.
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov kostik...@gmail.comwrote:
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
I have a memory subsystem design question that I'm hoping someone can
answer.
I've been looking at a machine that is completely out of memory, as
Alan writes:
In conclusion, I think it's time that we change M_NOWAIT so that it doesn't
dig any deeper into the cache/free page queues than M_WAITOK does and
reintroduce a M_USE_RESERVE-like flag that says dig deep into the
cache/free page queues. The trouble is that we then need to identify
On 11 November 2012 13:40, Alan Cox alan.l@gmail.com wrote:
Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was
well understand that it should only be used by interrupt handlers.
The trouble is that M_NOWAIT conflates two orthogonal things. The obvious
being that
I think very few of the m_nowaits actually need the reserve behavior. We should
probably switch away from it digging that deep by default and introduce a flag
and/or a per thread flag to set the behavior.
Sent from my iPhone
On Nov 11, 2012, at 4:32 PM, Dieter BSD dieter...@engineer.com
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
I have a memory subsystem design question that I'm hoping someone can answer.
I've been looking at a machine that is completely out of memory, as in
v_free_count = 0,
v_cache_count = 0,
I wondered how a machine could
29 matches
Mail list logo
