[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] 2.3.6-pre1 posted

From: Frantisek Hrbata
Subject: Re: [Dazuko-devel] 2.3.6-pre1 posted
Date: Mon, 28 Jul 2008 20:54:57 -0500

On Mon, 28 Jul 2008 20:05:14 +0200
John Ogness <address@hidden> wrote:

> On 2008-07-22, Frantisek Hrbata <address@hidden> wrote:
> > generally it is a bad idea to use GFP_ATOMIC for all allocations
> > like dazuko did.  GFP_ATOMIC should be used only when it is really
> > necessary, like in the irq where you can not block. With GFP_ATOMIC
> > kernel has limited possibilities how to get memory(pages) for your
> > allocation. So there is much bigger possibility that the allocation
> > fails.
> I've been reworking the locking to avoid mallocs while having a
> lock. In many places, this is not proving to be easy.
> But quite frankly, I was not aware that spinlocks were being used for
> SMP. There is no reason that spinlocks are needed in *any* portion of
> the Dazuko code. Dazuko uses locking primarily for inter-process
> communication and very rarely for protecting critical sections.
> I need to see what kinds of locks I am *supposed* to be using. Any
> tips would be greatly appreciated. (ie. what types of locks may be
> held while performing GFP_KERNEL memory allocation?)


you can use mutex(semaphore). It is safe to sleep while holding a mutex, 
because if other process can not acquire the mutex it is put to sleep and
rescheduled in contrast to spinlock. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]