----- Original Message ----- > Dave Anderson <anderson@xxxxxxxxxx> writes: > > > That's kind of cluttered -- I was thinking of something like this: > > > > crash> kmem ffffea0004de2c00 > > CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS > > SSIZE > > ffff88013a719900 ext4_inode_cache 2200 730 742 53 > > 32k > > SLAB MEMORY NODE TOTAL ALLOCATED FREE > > RED_ZONE > > ffffea0004de2c00 ffff8801378b0000 0 14 2 12 8 > > FREE / [ALLOCATED] > > ffff8801378b0000 (cpu 0 cache) > > [ffff8801378b08b8] > > > > or better yet, this: > > > > crash> kmem ffffea0004de2c00 > > CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS > > SSIZE > > ffff88013a719900 ext4_inode_cache 2200 730 742 53 > > 32k > > SLAB MEMORY NODE TOTAL ALLOCATED FREE > > ffffea0004de2c00 ffff8801378b0000 0 14 2 12 > > FREE / [ALLOCATED] SLAB_RED_ZONE: 8 > > ffff8801378b0000 (cpu 0 cache) > > [ffff8801378b08b8] > > I see what you say. However, my usual usage of kmem is to get the data > address of object (I was thinking the most users are same usage). > > crash> kmem <pointer in stack> > info for data address > > copy & paste <data address> > crash> p *(struct inode *)<data address> Why not copy-and-paste the address from <pointer in stack>? Or use "bt -FF" to get the kmem cache type, and skip using "kmem" entirely? ;-) Dave > > So I want to display <data address> itself (btw, cluttered is same with > "cpu %d cache"). BTW, ->red_left_pad itself can get from CACHE's > address, so if displaying <data address> is unacceptable, I would not > have big interest to add ->red_left_pad itself. > > If this usage is only me, unfortunate though, I will apply this patch by > myself. > > Thanks. > -- > OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
