Messages in this thread | | | Date | Thu, 1 Aug 2002 18:52:36 +0530 | From | Dipankar Sarma <> | Subject | Re: [Lse-tech] [RFC] per cpu slab fix to reduce freemiss |
| |
On Thu, Aug 01, 2002 at 07:42:10AM -0500, Mala Anand wrote: > > > Tony Luck wrote.. > >> No I am using the object(beginning space) to store the links. When > >> allocated, I can initialize the space occupied by the link address. > > >You can't use the start of the object (or any other part) in this way, > >you'll have no way to restore the value you overwrote. > > >Take a look at Jeff Bonwick's paper on slab allocators which explains > >this a lot better than I can: > > > > http://www.usenix.org/publications/library/proceedings/bos94/full_papers/bon > > >wick.a > > In the present design there is a limit on how many free objects are held > in the per cpu array. So when an object is freed it might end in another > cpu more often. The main cost lies in memory latency than execution of > initializing the fields. I doubt if we get the same gain as explained in > the paper by preserving the fields between uses on an SMP/NUMA machines. > > I agree that preserving read only variables that can be used between uses > will help performance. We still can do that by revising the assumption to > leave the first 4 or whatever bytes needed to store the links. What do you > think?
Mala,
Isn't it possible to tune the cpucache limit by writing to /proc/slabinfo so that you avoid frequent draining of free objects ? Am I missing something here ?
Thanks -- Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net Linux Technology Center, IBM Software Lab, Bangalore, India. - 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/
| |