LKML Archive on
help / color / mirror / Atom feed
From: Christoph Hellwig <>
To: Nick Piggin <>
Cc: Linux Kernel Mailing List <>,
	Linux Memory Management List <>,
Subject: Re: vm/fs meetup in september?
Date: Mon, 25 Jun 2007 07:35:45 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Jun 24, 2007 at 06:23:45AM +0200, Nick Piggin wrote:
> I'd just like to take the chance also to ask about a VM/FS meetup some
> time around kernel summit (maybe take a big of time during UKUUG or so).

I won't be around until a day or two before KS, so I'd prefer to have it
after KS if possible.

> I don't want to do it in the VM summit, because that kind of alienates
> the filesystem guys. What I want to talk about is anything and everything
> that the VM can do better to help the fs and vice versa.  I'd like to
> stay away from memory management where not too applicable to the fs.

As more of a filesystem person I wouldn't mind it being attached to a VM
conf.  In the worst case we'll just rename it VM/FS conference.  When and
where is it scheduled?

> - the address space operations APIs, and their page based nature. I think
>   it would be nice to generally move toward offset,length based ones as
>   much as possible because it should give more efficiency and flexibility
>   in the filesystem.
> - write_begin API if it is still an issue by that date. Hope not :)
> - truncate races
> - fsblock if it hasn't been shot down by then

Don't forget high order pagecache please.

> - how to make complex API changes without having to fix most things
>   yourself.

More issues:

 - aio once again
 - refactoring the dio code to separate locking down user VM and doing
   the actual page based I/O.  I've seen valid requests from kernel
   initiated direct I/O from a few real world linux users.
 - generic code for delayed allocation and writeout using efficient
   multi-page allocator calls.  I'll hopefully have an example (lifted XFS
   code) by then
 - what to do about reads/writes from kernelspace.  Currently we have
   some places (loop mostly) calling directly into ->prepare_write / 
   ->commit_write which is completely wrong from the layerin perspective
   and a locking nightmare for distributed or generally more complex
   filesystems.  And we have a lot of places using set_fs/set_ds and
   calling into ->write.  The first category could probably be covered
   by using the splice infrastructure, but for the latter we'd want
   something more optimal and less hacky, especially given all the overhead
   related avoiding deadlocks involing the user address space in the
   generic write path.  Maybe it's time for generic_file_kernel_write?

  reply	other threads:[~2007-06-25  6:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-24  4:23 Nick Piggin
2007-06-25  6:35 ` Christoph Hellwig [this message]
2007-06-25 17:26   ` Zach Brown
2007-06-26  2:35   ` Nick Piggin
2007-06-26  3:23     ` Andreas Dilger
2007-06-26 12:38     ` Chris Mason
2007-06-30  9:31     ` Christoph Hellwig
2007-06-30 12:35       ` Martin J. Bligh
2007-06-26  0:08 ` Jared Hulbert
2007-06-26  6:05   ` Christoph Hellwig
2007-06-26 17:07     ` Jared Hulbert
2007-06-30  9:32       ` Christoph Hellwig
2007-06-30 10:02         ` peter
2007-06-30 10:09           ` Christoph Hellwig
2007-06-30 21:58           ` Al Boldi
2007-07-02 17:26             ` Jared Hulbert
2007-07-02 17:44         ` Jared Hulbert
2007-07-02 23:04           ` Jörn Engel
2007-07-03  0:46             ` Jared Hulbert
2007-07-03 12:25               ` Jörn Engel
2007-07-04  0:28                 ` Dongjun Shin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: vm/fs meetup in september?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).