lkml.org 
[lkml]   [2002]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] generalized spin_lock_bit


    On 20 Jul 2002, Robert Love wrote:
    >
    > My assumption was similar - that the bit locking may be inefficient on
    > other architectures - so I put the spin_lock_bit code in per-arch
    > headers.

    Well, but you also passed it an unsigned long, and the bit number.

    Which at least to me implies that they have to set that bit.

    Which is totally unnecessary, if they _instead_ decide to set something
    else altogether.

    For example, the implementation on pte_chain_lock(page) might be something
    like this instead:

    static void pte_chain_lock(struct page *page)
    {
    unsigned long hash = hash(page) & PTE_CHAIN_MASK;
    spin_lock(pte_chain[hash]);
    }

    static void pte_chain_unlock(struct page *page)
    {
    unsigned long hash = hash(page) & PTE_CHAIN_MASK;
    spin_unlock(pte_chain[hash]);
    }

    > In other words, I assumed we may need to make some changes but to
    > bit-locking in general and not rip out the whole design.

    bit-locking in general doesn't work. Some architectures can sanely only
    lock a byte (or even just a word).

    Linus

    -
    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-03-22 13:27    [W:0.021 / U:0.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site