On Sun, 2 Jul 2006, Marcelo Tosatti wrote:
> > > I was, of course, referring to the unpleasant requirement that the object
> > > layout start with an atomic_t.
> >
> > Is that such a problem? It reduces the amount of indirect function calls
> > needed.
>
> Need to benchmark I guess.
I think is pretty obvious. With atomic refcounters you can simply scan
a slab for unused objects without any callbacks. Needing a callback for
every single object is a waste of resources and will limit reclaim
efficiency. You would have to do 120 callbacks on some slabs just to
figure out that it is worth trying to free objects in that
particular slab block.
> I agree with Andrew, an atomic counter to indicate usage of the objects
> is too simplistic (other than being unpleasant).
Cannot see a valid reason so far to draw that conclusion. With the right
convention the atomic refcounter can be used as an indicator that the
object is being freed (refcnt = 0), not in use (refcnt = 1) or in active
use (refcnt=2). The easy and efficient access to this kind of knowledge
about an object is essential for reclaim.
> > > How do you propose handling the locking? dcache is passed a bare pointer
> > > and no locks are held, but it is guaranteed that the object won't be freed
> > > while it's playing with it?
> >
> > The reference counter can be used to insure that the object is not freed.
>
> Locking is pretty tricky...
Not at all. You do an atomic_inc_if_not_zero from the destructor and then
either will hold the object to good or you were unable to increment the
refcount and therefore you can give up and return because the object
is already being freed.
The tricky locking part comes later when the destructor has to establish
the locks to get all links to the object released.
> What it does is to create a small set callbacks to invoke higher-level
> code:
>
> +struct slab_reclaim_ops {
> + int (*objp_is_freeable)(void *objp);
> + int (*objp_release)(void *objp);
> + int (*objp_lock)(void *objp);
> + int (*objp_unlock)(void *objp);
> +};
>
> Which are used by generic SLAB code to check for, and release, fully
> freeable pages (you've seen it before, from last year). It contains a
> dcache implementation.
Ok. I will have a look at that. But these callbacks are too heavy for my
taste. A refcounter could avoid all of that.
> You really need cache specific information, such as the tree nature of
> dentry references.
Only the cache knows that. The cache provides a destructo. In that
destructor the tree nature of the dentries can be considered. The
destructor knows about the tree nature of the slab and that can navigate
through the dependency structures that the object may be a part of.
> Christoph, I'm afraid that not using the LRU information can be harmful
> to certain workloads...
It can be very beneficial too since removing the LRU will avoid locking in
certain situations and it will shrink the objects. We already have lists
of all the objects in the slab. The LRU is redundant in some way.
Of course there is the challenge of preserving the LRU like behavior using
the slab lists. But I think it may be sufficiently approximated by the
LRU ness of the used slab list and the push back to the partial lists
whenever we touch a slab during reclaim (we free some objects so the slab
has to move).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
