lkml.org 
[lkml]   [2005]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 03/05] mm rationalize __alloc_pages ALLOC_* flag names
    From
    Date
    On Tue, 2005-11-15 at 01:03 -0800, Andrew Morton wrote:
    > Nick Piggin <nickpiggin@yahoo.com.au> wrote:
    > >
    > > Paul Jackson wrote:
    > > > Rationalize mm/page_alloc.c:__alloc_pages() ALLOC flag names.
    > > >
    > >
    > > I don't really see the need for this. The names aren't
    > > clearly better, and the downside is that they move away
    > > from the terminlogy we've been using in the page allocator
    > > for the past few years.
    >
    > I thought they were heaps better, actually.
    >
    > -#define ALLOC_NO_WATERMARKS 0x01 /* don't check watermarks at all */
    > -#define ALLOC_HARDER 0x02 /* try to alloc harder */
    > -#define ALLOC_HIGH 0x04 /* __GFP_HIGH set */
    > +#define ALLOC_DONT_DIP 0x01 /* don't dip into memory reserves */
    > +#define ALLOC_DIP_SOME 0x02 /* dip into reserves some */
    > +#define ALLOC_DIP_ALOT 0x04 /* dip into reserves further */
    > +#define ALLOC_MUSTHAVE 0x08 /* ignore all constraints */
    >
    > very explicit.

    maybe.
    however... if names get changed anyway, maybe name them based on intent?

    ALLOC_NORMAL
    ALLOC_KERNELTHREAD
    ALLOC_VMCAUSED
    ALLOC_WOULDDEADLOCK

    or something.. yes these are lame

    perhaps both are needed.. bitflags for the implementation, and defines
    based on usage that are compounded bitflags..


    -
    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/

    \
     
     \ /
      Last update: 2005-11-15 11:02    [W:4.700 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site