xfs
[Top] [All Lists]

Re: [PATCH] Tweak tracing allocation sizes

To: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH] Tweak tracing allocation sizes
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Tue, 02 Sep 2008 16:12:14 +1000
In-reply-to: <20080902055604.GD15962@disturbed>
References: <48BCD3BE.5040107@xxxxxxx> <20080902055604.GD15962@disturbed>
Reply-to: lachlan@xxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080707)
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?

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