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, 2
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:
>
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 drivin
Hey, great catch!
adrian
On 13 November 2012 12:04, Alan Cox 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
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
>>> wrote:
>>>
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
> I ha
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,
On 11/12/12 3:49 PM, Adrian Chadd wrote:
On 12 November 2012 15:26, Alan Cox 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
--- On Mon, 11/12/12, Alan Cox wrote:
> From: Alan Cox
> Subject: Re: Memory reserves or lack thereof
> To: "Konstantin Belousov"
> Cc: "Sushanth Rai" , a...@freebsd.org,
> p...@freebsd.org, "StevenSears" ,
> "freebsd-hackers@freebsd.org
On 12 November 2012 15:26, Alan Cox 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 partic
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
http://lis
.. 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 "freebsd-hackers-unsubscr...@
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
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.
wrote:
> From: Konstantin Belousov
> Subject: Re: Memory reserves or lack thereof
> To: a...@freebsd.org
> Cc: p...@freebsd.org, "Sears, Steven" ,
> "freebsd-hackers@freebsd.org"
> Date: Monday, November 12, 2012, 5:36 AM
> On Sun, Nov 11, 2012 at 03:40:24
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 thi
On Nov 12, 2012, at 4:11 AM, Andre Oppermann 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 namespace c
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
>> wrote:
>>
>>> On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
I have a memory subsystem design question that I'
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 (callout
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 a
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
> > wrote:
> >
> > > On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
> > > > I have a memory sub
On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
> wrote:
>
> > 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 b
On 12.11.2012 03:02, Adrian Chadd wrote:
On 11 November 2012 13:40, Alan Cox 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 o
On 11.11.2012 22:40, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote:
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 was
well understand
On 11 November 2012 20:24, Alfred Perlstein 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 perfectly fine
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" wrote:
> Alan writes:
>>
On 11 November 2012 13:40, Alan Cox 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 the allocation s
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 ident
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote:
> 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
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 co
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 completely run out of memory like this,
especially after finding a lack of
30 matches
Mail list logo
