Re: Disposal of a misleading M_TRYWAIT



Ruslan Ermilov wrote:
On Sat, Mar 22, 2008 at 09:01:23PM -0700, Sam Leffler wrote:
We made a decision a while back to not use malloc flags for mbuf routine arguments.

While I can see the point in this (if we ever change the
mbuf allocator from UMA to something else), like I said
in my email, a lot of code already uses malloc flags for
this.

There are even assertions to verify it.

I think this was OBE, now mbuf.h says:

: /*
: * Flags specifying how an allocation should be made.
: *
: * The flag to use is as follows:
: * - M_DONTWAIT or M_NOWAIT from an interrupt handler to not block allocation.
: * - M_WAIT or M_WAITOK from wherever it is safe to block.
: *
: * M_DONTWAIT/M_NOWAIT means that we will not block the thread explicitly and
: * if we cannot allocate immediately we may return NULL, whereas
: * M_WAIT/M_WAITOK means that if we cannot allocate resources we
: * will block until they are available, and thus never return NULL.
: *
: * XXX Eventually just phase this out to use M_WAITOK/M_NOWAIT.
: */
: #define MBTOM(how) (how)
: #define M_DONTWAIT M_NOWAIT
: #define M_TRYWAIT M_WAITOK
: #define M_WAIT M_WAITOK


Yes, looks like someone broke it. Hence the confusion/pollution reappeared.

The original suggestion was to purge M_TRYWAIT which was fine with me. If someone wants to sweep the tree and rename everything I'm not going to argue but it makes diffs against old code noisier and (as I said) for little gain.

Sam
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: [PATCH v2] slab,slub: ignore __GFP_WAIT if were booting or suspending
    ... flags is a bit dubious. ... * The slab allocator is initialized with interrupts disabled. ... * sure early boot allocations don't accidentally enable interrupts. ... Need this for bootstrapping a per node allocator. ...
    (Linux-Kernel)
  • Re: [patch] SLQB slab allocator (try 2)
    ... Subject: SLUB: Do not pass 8k objects through to the page allocator ... return kmalloc_large(size, flags); ... return kmalloc_large(size, gfpflags); ...
    (Linux-Kernel)
  • Re: [patch] SLQB slab allocator (try 2)
    ... Subject: SLUB: Do not pass 8k objects through to the page allocator ... return kmalloc_large(size, flags); ... return kmalloc_large(size, gfpflags); ...
    (Linux-Kernel)
  • Re: [PATCH] Allocate module.ref array dynamically
    ... And other flags become impossible, ... Make the dynamic percpu allocator use the static percpu system. ... GFP_HARDWALL could all be relevant for a dynamically extending percpu ...
    (Linux-Kernel)
  • Re: [patch] SLQB slab allocator (try 2)
    ... allocator pass-through and just add a kmalloc cache for 8K allocations. ... return kmalloc_large(size, flags); ... struct kmem_cache *s; ... return kmalloc_large(size, gfpflags); ...
    (Linux-Kernel)