[Top] [All Lists]

Re: [PATCH] Tweak tracing allocation sizes

To: lachlan@xxxxxxx
Subject: Re: [PATCH] Tweak tracing allocation sizes
From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Tue, 02 Sep 2008 08:50:52 +0200
Cc: xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <48BCD93E.9040407@xxxxxxx> (Lachlan McIlroy's message of "Tue, 02 Sep 2008 16:12:14 +1000")
References: <48BCD3BE.5040107@xxxxxxx> <20080902055604.GD15962@disturbed> <48BCD93E.9040407@xxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux)
Lachlan McIlroy <lachlan@xxxxxxx> writes:

> 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 - maybe a very large global trace buffer that is allocated at 
> mount
> time and shared by all inodes?

You could use vmalloc(). While that is also not fast it will at least
not stall.



<Prev in Thread] Current Thread [Next in Thread>