Re: [PATCH] Tweak tracing allocation sizes

[Dave Chinner <david@fromorbit.com>]

On Tue, Sep 02, 2008 at 04:12:14PM +1000, Lachlan McIlroy wrote:
> Dave Chinner wrote:
>> On Tue, Sep 02, 2008 at 03:48:46PM +1000, Lachlan McIlroy wrote:
>>> The size of a single ktrace entry is 16 pointers so 128 bytes.  For the case
>>> of XFS_RW_KTRACE_SIZE which is 128 entries this equates to 16KB and on a system
>>> with 4KB pages that is under memory pressure this can stall that process for a
>>> significant time while it hunts for 4 free pages.  Cutting this value back to
>>> 32 means it will only need one page.
>>
>> That will effectively render that type of tracing useless - 32
>> entries is not enough history to capture enough
>> read/write/map/invalidate trace events to be meaningful. In the past
>> I've often had to increase this to 256 or 512 entries to be able to
>> capture the events necessary to debug problems...
>
> A system that constantly locks up and/or stalls is useless too.  Allocating
> 4 or more pages for every inode just taxes the system.  Can you offer an
> alternative

Buy more memory for your test machine? (I can't beleive I'm saying that
to an SGI guy ;)

How about using the SLUB allocator rather than SLAB and tweaking
it's settings to do order 2 allocations for every slab so most
allocations are doing order 2 allocations?

> - maybe a very large global trace buffer that is allocated at mount
> time and shared by all inodes?

Sure, we've got that for various other trace types (e.g. the "vnode"
trace). You'd need to add idbg stuff for filtering based on the
inode the buffer belongs to....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com