[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d6a94c50701102257o2a6091f8m9695eb22311ced7d@mail.gmail.com>
Date: Thu, 11 Jan 2007 14:57:23 +0800
From: Aubrey <aubreylee@...il.com>
To: "Alexander Shishkin" <alexander.shishckin@...il.com>
Cc: "Linus Torvalds" <torvalds@...l.org>,
"Hua Zhong" <hzhong@...il.com>, "Hugh Dickins" <hugh@...itas.com>,
linux-kernel@...r.kernel.org, hch@...radead.org,
kenneth.w.chen@...el.com, akpm@...l.org, mjt@....msk.ru
Subject: Re: O_DIRECT question
On 1/11/07, Alexander Shishkin <alexander.shishckin@...il.com> wrote:
> On 1/11/07, Aubrey <aubreylee@...il.com> wrote:
> > Firstly I want to say I'm working on no-mmu arch and uClinux.
> > After much of file operations VFS cache eat up all of the memory.
> > At this time, if an application request memory which order > 3, the
> > kernel will report failure.
> >
> > uClinux use a memory mapped MTD driver to store rootfs, of course it's
> > in the ram,
> > So I don't need VFS cache to improve performance. And when order > 3,
> > __alloc_page() even doesn't try to shrunk cache and slab, just report
> > failure.
> >
> > So my thought is remove cache, or limit it. But currently there seems
> > to be no way in the kernel to do it. So I want to try to use
> > O_DIRECT. But it seems not to be a right way.
> One possibility might be to poke the open method in struct
> file_operations of your fs like
>
> static int my_open_file(struct inode *inode, struct file *filp)
> {
> filp->f_flags |= O_DIRECT;
> ...
> }
>
> which is a nasty thing to do but might give you an idea of what happens next.
Thanks, I'll try to see what happens next on my side.
-Aubrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists