[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.00.1001280028160.2909@abydos.NerdBox.Net>
Date: Thu, 28 Jan 2010 00:32:32 -0800 (PST)
From: Steve VanDeBogart <vandebo-lkml@...dBox.Net>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Chris Frost <frost@...ucla.edu>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Benny Halevy <bhalevy@...asas.com>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: add fincore(2) (mincore(2) for file descriptors)
On Thu, 28 Jan 2010, Andrew Morton wrote:
> On Wed, 27 Jan 2010 23:42:35 -0800 (PST) Steve VanDeBogart <vandebo-lkml@...dBox.Net> wrote:
>
>>> Is it likely that these changes to SQLite and Gimp would be merged into
>>> the upstream applications?
>>
>> Changes to the GIMP fit nicely into the code structure, so it's feasible
>> to push this kind of optimization upstream. The changes in SQLite are
>> a bit more focused on the benchmark, but a more general approach is not
>> conceptually difficult. SQLite may not want the added complexity, but
>> other database may be interested in the performance improvement.
>>
>> Of course, these kernel changes are needed before any application can
>> optimize its IO as we did with libprefetch.
>
> That didn't really answer my question.
>
> If there's someone signed up and motivated to do the hard work of
> getting these changes integrated into the upstream applications then
> that makes us more interested. If, however it was some weekend
> proof-of-concept hack which shortly dies an instadeath then... meh,
> not so much.
Sorry I misunderstood. The maintainer of GraphicsMagick has already
contacted us about making changes similar to our GIMP changes. So yes,
there is interest in really using these changes.
--
Steve
--
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