[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?)
Hi,
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.
-FH