On Mon, 2008-03-03 at 15:35 -0500, Dave Anderson wrote: <snip> > >>> > >>> so we know the object address, which slab it is in, and the offset, > >>> (thus can derive the raw value), all in one shot? > >>> > >> You've done a fine bit of debugging your issue... > >> > >> But I think that's a bit of overkill for each address reference. > >> > >> To do it right it would have to walk slab chains to gather all of the > >> information needed by the "kmem -S" output, which can be extremely > >> time-consuming, and potentially error-prone if the slab chain is > >> corrupt or being modified while running on a live system. > > > > full agree. realized now. > > > > then here is my question, how "kmem -s <addr>" find out which slab this > > address belong to? by only looking at the page? > > The kmem_cache and containing slab addresses are stashed in unused > fields of the page structure of the object's virtual address. ic. good to know this. > > > > > then here is my revised suggestion. can we split this into 2 steps? > > > > (1) rd -S show [raw address: cache name] > > > > (this is a great to have since do rd 2 times, one with -S and another > > without -S is tedious.) > > But in your case, for example, I'm presuming you've done a "bt -f", > and simply would like a symbols/slab translation of a chunk of memory > making up one of the stack frames, so you do a subsequent "rd -S" of > that memory area. Doesn't seem that tedious to me... have to agree. > > > > > (2) and kmem -s <address> > > > > show which slab it is in and optionally (with a new option like -O) show > > the object? > > Not following -- "kmem -s <address>" does show which slab it's in. i emphasize on "and optionally...", ;) > And if you're asking whether the object can be dumped as the structure > type it is (?), well, how would it be possible from the crash utility's > viewpoint to even know what type of data structure it is? no. what i mean is kmem -s <address> does not give me the object address crash> kmem -s 000001007877c8d4 CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE 10037ffc080 dentry_cache 240 9429 10560 660 4k SLAB MEMORY TOTAL ALLOCATED FREE 1007877c040 1007877c088 16 9 7 FREE / [ALLOCATED] [1007877c8d4] i still have to use kmem -S to find out 1007877c808 is the object that contain this address. nice if crash can do this for me. > > If you want to look at all of the objects in a slab represented > as data structures, you're going to have supply the knowledge of > what data structure they are. It's simple enough, just do a "kmem -S" > into a file, delete everything except the object addresses that you're > interested in, insert "struct whatever" in front of each address, save this is exactly what i did when i have to do work like this by using gawk, tr, and grep. > the file -- and run it as crash input file. > how to do this? i know crash -i can run a file at beginning. but how to run command in a file at any moment? > > > > (this is nice to have). > > > > thanks. > > Look, you can have it do anything you want... > > However, keep in mind that there are 4 diffenent kmem slab paradigms > supported (the "original", the first verion with per-cpu objects, the > second version with per-cpu objects, and now the completely new CONFIG_SLUB > subsystem). All of them would have to be supported. And the code that does > the object dumping is somewhat replicated and embedded in the "kmem -S" support > code, so it's not a simple re-use of an existing function, which I've done > to get the simple "rd -S" output. ic. > > Dave > -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
