| To: | Andi Kleen <andi@xxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] Tweak tracing allocation sizes |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Wed, 3 Sep 2008 08:06:35 -0400 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, lachlan@xxxxxxx, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx> |
| In-reply-to: | <20080903070654.GP18288@one.firstfloor.org> |
| References: | <48BCD3BE.5040107@sgi.com> <20080902055604.GD15962@disturbed> <48BCD93E.9040407@sgi.com> <87fxojvy5v.fsf@basil.nowhere.org> <20080902215516.GE9204@infradead.org> <20080903070654.GP18288@one.firstfloor.org> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.18 (2008-05-17) |
On Wed, Sep 03, 2008 at 09:06:54AM +0200, Andi Kleen wrote: > On Tue, Sep 02, 2008 at 05:55:16PM -0400, Christoph Hellwig wrote: > > On Tue, Sep 02, 2008 at 08:50:52AM +0200, Andi Kleen wrote: > > > > 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. > > > > In fact kmem_alloc first tries vmalloc, and then falls back to slab > > when it fails. See fs/xfs/linux-2.6/kmem.c:kmem_alloc(). > > You mean the other way around? No, take a look at the function. I guess the intent is that vmalloc can fail due to a full vmalloc area and kmalloc could theoretically still scucceed. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] Tweak tracing allocation sizes, Andi Kleen |
|---|---|
| Next by Date: | Re: [PATCH V2] Don't do I/O beyond eof when unreserving space, Christoph Hellwig |
| Previous by Thread: | Re: [PATCH] Tweak tracing allocation sizes, Andi Kleen |
| Next by Thread: | Re: [PATCH] Fix use-after-free with buffers, Lachlan McIlroy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |