Re: [PATCH, RFC 1/3] Add sem_getcount() to arches that lack it

From: Jody McIntyre (scjody_at_modernduck.com)
Date: 03/11/05

  • Next message: Benjamin Herrenschmidt: "[PATCH] ppc32: move powermac backlight stuff to a workqueue" 
    Date:	Fri, 11 Mar 2005 00:31:44 -0500
To: Andrew Morton <akpm@osdl.org>

    On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote:
    > Jody McIntyre <scjody@modernduck.com> wrote:
    > >
    > > parisc and frv define sem_getcount() in semaphore.h, which returns the
    > > current semaphore value. This is cleaner than doing
    > > atomic_read(&semaphore.count), currently done in
    > > drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work
    > > on all architectures if sem_getcount() is added.
    >
    > That's a fairly bizarre thing to want to do. Would it be hard to modify
    > xfs and 1394 to stop wanting to read a semaphore's up() count?

    The count is the number of free transaction labels (1394 async is
    transaction-based) and is initialized to 64. When a new transaction label
    is needed, the requestor does a down(), then locks the tlabel variables
    and allocates a new one. When a transaction label is freed, an up()
    occurs. The semaphore's up() count is therefore the number of free
    tlabels, and the number of outstanding transactions is (64 - count). I
    can imagine situations in which this would be a useful statistic, but
    I'm not sure any of them actually exist.

    I haven't investigated xfs, but modifying 1394 would be fairly easy. I
    could add a second variable that tracks the up() count, or just drop the
    sysfs attribute that reports the number. The first option seems a bit
    wasteful, but only slightly. I thought this patch was worthwhile based
    on xfs wanting to do this and 3 arches already having (unused)
    implementations of sem_getcount/sema_count.

    If this patch isn't accepted, we should get rid of the xfs and 1394
    hacks and delete sem_getcount (parisc, frv) and sema_count (arm) as they
    are unused.

    Jody

    >
    > (Why do they want to do this anyway?) 

    -- 
-
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/
  • Next message: Benjamin Herrenschmidt: "[PATCH] ppc32: move powermac backlight stuff to a workqueue"