On Fri, Sep 20, 2002 at 11:40:16AM +0200, Ingo Molnar wrote:
> > > + if (cmpxchg(&map->page, NULL, page))
> > > + free_page(page);
> > Note that this piece breaks compilation for every arch that does not
> > have cmpxchg implementation.
> > This is the case with x86 (with CONFIG_X86_CMPXCHG undefined, e.g.
i386),
> > ARM, CRIS, m68k, MIPS, MIPS64, PARISC, s390, SH, sparc32, UML (for
x86).
> we need a cmpxchg() function in the generic library, using a spinlock.
>But this is not safe for arches that provides SMP but does not provide
>cmpxchg in hadware, right?
>I mean it is only safe to use such spinlock-based function if
>all other places read and write this value via special functions that are
>also taking this spinlock.
>Do you think we can count on this?
> Bye,
> Oleg
First of all, using bitmap is not that good as exposed in this
mailing list (I think some good guys at IBM already implememted
bitmap for pids as part of Linux scalability enhancements & I
remember they discussed pros & cons too) & atomic operations
are not that cheap anyway. However it is good to have something
better than the previous one.
~Hanu
Hello!
On Fri, Sep 20, 2002 at 06:42:46PM +0530, Hanumanthu. H wrote:
> are not that cheap anyway. However it is good to have something
> better than the previous one.
This is only true if it works for everyone.
Bye,
Oleg
On Fri, 20 Sep 2002, Hanumanthu. H wrote:
> First of all, using bitmap is not that good as exposed in this
> mailing list (I think some good guys at IBM already implememted
> bitmap for pids as part of Linux scalability enhancements & [...]
i mentioned that patch in earlier emails, and it is a whole different
thing. The patch built a completely new bitmap *every* time we hit an
already allocated PID, to find the next 'safe range'. The new PID
allocator in 2.5.37 keeps one bitmap and does a single set-bit map
operation in the fastpath and does a fast bitscan forward even in the
worst case.
> remember they discussed pros & cons too) & [...]
(that approach was pretty gross i have to say.)
> [...] atomic operations are not that cheap anyway. [...]
huh?
Ingo