Re: GFP_ATOMIC page allocation failures. - Kernel

This is a discussion on Re: GFP_ATOMIC page allocation failures. - Kernel ; Nick Piggin wrote: > On Thursday 03 April 2008 05:18, Jeff Garzik wrote: >> Turning to Nick's comment, >> >> > It's still actually nice to know how often it is happening even for >> > these known good sites ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: GFP_ATOMIC page allocation failures.

  1. Re: GFP_ATOMIC page allocation failures.

    Nick Piggin wrote:
    > On Thursday 03 April 2008 05:18, Jeff Garzik wrote:


    >> Turning to Nick's comment,
    >>
    >> > It's still actually nice to know how often it is happening even for
    >> > these known good sites because too much can indicate a problem and
    >> > that you could actually bring performance up by tuning some things.

    >>
    >> then create a counter or acculuation buffer somewhere.
    >>
    >> We don't need spew every time there is memory pressure of this magnitude.

    >
    > Not a complete solution. Counter would be nice, but you need backtraces
    > and want a way to more proactively warn the user/tester/developer.
    >
    > I agree that I don't exactly like adding nowarns around, and I don't think
    > places like driver writers should have to know about this stuff.


    What about reverse ratelimiting: If the limit is reached, a backtrace will be
    generated (and, off cause, positively ratelimited)?

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: GFP_ATOMIC page allocation failures.

    On Friday 04 April 2008 20:52, Bodo Eggert wrote:
    > Nick Piggin wrote:
    > > On Thursday 03 April 2008 05:18, Jeff Garzik wrote:
    > >> Turning to Nick's comment,
    > >>
    > >> > It's still actually nice to know how often it is happening even for
    > >> > these known good sites because too much can indicate a problem and
    > >> > that you could actually bring performance up by tuning some things.
    > >>
    > >> then create a counter or acculuation buffer somewhere.
    > >>
    > >> We don't need spew every time there is memory pressure of this
    > >> magnitude.

    > >
    > > Not a complete solution. Counter would be nice, but you need backtraces
    > > and want a way to more proactively warn the user/tester/developer.
    > >
    > > I agree that I don't exactly like adding nowarns around, and I don't
    > > think places like driver writers should have to know about this stuff.

    >
    > What about reverse ratelimiting: If the limit is reached, a backtrace will
    > be generated (and, off cause, positively ratelimited)?


    I was thinking about that. I got as far as writing a simple patch to
    printk so that it would not start to trigger until it gets a 2nd event
    within 'n' jiffies of the first.

    But actually developers do sometimes want see the event even if it is
    relatively infrequent...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: GFP_ATOMIC page allocation failures.

    On Fri, 4 Apr 2008, Nick Piggin wrote:

    > On Friday 04 April 2008 20:52, Bodo Eggert wrote:
    > > Nick Piggin wrote:
    > > > On Thursday 03 April 2008 05:18, Jeff Garzik wrote:
    > > >> Turning to Nick's comment,
    > > >>
    > > >> > It's still actually nice to know how often it is happening even for
    > > >> > these known good sites because too much can indicate a problem and
    > > >> > that you could actually bring performance up by tuning some things.
    > > >>
    > > >> then create a counter or acculuation buffer somewhere.
    > > >>
    > > >> We don't need spew every time there is memory pressure of this
    > > >> magnitude.
    > > >
    > > > Not a complete solution. Counter would be nice, but you need backtraces
    > > > and want a way to more proactively warn the user/tester/developer.
    > > >
    > > > I agree that I don't exactly like adding nowarns around, and I don't
    > > > think places like driver writers should have to know about this stuff.

    > >
    > > What about reverse ratelimiting: If the limit is reached, a backtrace will
    > > be generated (and, off cause, positively ratelimited)?

    >
    > I was thinking about that. I got as far as writing a simple patch to
    > printk so that it would not start to trigger until it gets a 2nd event
    > within 'n' jiffies of the first.


    I think there was a standalone ratelimit function. I'd use it like this:

    static atomic_alloc_ratelimit; /* needs to be initialized ... */

    {
    ...
    if (success)
    return mem;
    if(!debug && ratelimit(atomic_alloc_ratelimit))
    return err_ptr(-ENOMEM);
    if (printk_ratelimit(first line) > 0) {
    printk(rest);
    }
    }

    > But actually developers do sometimes want see the event even if it is
    > relatively infrequent...


    You shouldn't frighten the users either. /proc/sys/vm/debug?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: GFP_ATOMIC page allocation failures.

    On Friday 04 April 2008 22:35, Bodo Eggert wrote:
    > On Fri, 4 Apr 2008, Nick Piggin wrote:


    > > But actually developers do sometimes want see the event even if it is
    > > relatively infrequent...

    >
    > You shouldn't frighten the users either. /proc/sys/vm/debug?


    Hence changing the message a to make it clear that it is not a
    problem if it is infrequent.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: GFP_ATOMIC page allocation failures.

    On Sat, 5 Apr 2008, Nick Piggin wrote:
    > On Friday 04 April 2008 22:35, Bodo Eggert wrote:
    > > On Fri, 4 Apr 2008, Nick Piggin wrote:


    > > > But actually developers do sometimes want see the event even if it is
    > > > relatively infrequent...

    > >
    > > You shouldn't frighten the users either. /proc/sys/vm/debug?

    >
    > Hence changing the message a to make it clear that it is not a
    > problem if it is infrequent.


    If it's no problem when infrequent, and if it's possible and cheap (less
    extra code than sizeof(explanation)) to not show a message if it's
    infrequent, why should the users be bothered at all? The system needs less
    than one ms to do the job, the admin needs five minutes to grep the logs.

    --
    Top 100 things you don't want the sysadmin to say:
    72. My leave starts tomorrow.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread