Re: vm/fs meetup in september?
I'd like to reference a paper titled "FASS : A Flash-Aware Swap System". (http://kernel.kaist.ac.kr/~jinsoo/publication/iwssps05.pdf) The paper describes a technique that uses NAND flash as a swap device without FTL (Flash Translation Layer) or filesystem. It is not related with XIP, however. On 7/3/07, Jörn Engel <[EMAIL PROTECTED]> wrote: On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote: > > Right, the solution to swap problem is identical to the rw XIP > filesystem problem.Jörn, that's why you're the self-appointed > subject matter expert! All right. I'll try to make an important face whenever the subject comes up. Nick, do you have a problem if LogFS occupies two brainslots at the meeting? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote: > > Right, the solution to swap problem is identical to the rw XIP > filesystem problem.Jörn, that's why you're the self-appointed > subject matter expert! All right. I'll try to make an important face whenever the subject comes up. Nick, do you have a problem if LogFS occupies two brainslots at the meeting? Jörn -- Eighty percent of success is showing up. -- Woody Allen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote: Right, the solution to swap problem is identical to the rw XIP filesystem problem.Jörn, that's why you're the self-appointed subject matter expert! All right. I'll try to make an important face whenever the subject comes up. Nick, do you have a problem if LogFS occupies two brainslots at the meeting? Jörn -- Eighty percent of success is showing up. -- Woody Allen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
I'd like to reference a paper titled FASS : A Flash-Aware Swap System. (http://kernel.kaist.ac.kr/~jinsoo/publication/iwssps05.pdf) The paper describes a technique that uses NAND flash as a swap device without FTL (Flash Translation Layer) or filesystem. It is not related with XIP, however. On 7/3/07, Jörn Engel [EMAIL PROTECTED] wrote: On Mon, 2 July 2007 17:46:40 -0700, Jared Hulbert wrote: Right, the solution to swap problem is identical to the rw XIP filesystem problem.Jörn, that's why you're the self-appointed subject matter expert! All right. I'll try to make an important face whenever the subject comes up. Nick, do you have a problem if LogFS occupies two brainslots at the meeting? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On 7/2/07, Jörn Engel <[EMAIL PROTECTED]> wrote: On Mon, 2 July 2007 10:44:00 -0700, Jared Hulbert wrote: > > >So what you mean is "swap on flash" ? Defintively sounds like an > >interesting topic, although I'm not too sure it's all that > >filesystem-related. > > Maybe not. Yet, it would be a very useful place to store data from a > file as a non-volatile page cache. > > Also it is something that I believe would benefit from a VFS-like API. > I mean there is a consistent interface a management layer like this > could use, yet the algorithms used to order the data and the interface > to the physical media may vary. There is no single right way to do > the management layer, much like filesystems. > > Given the page orientation of the current VFS seems to me like there > might be a nice way to use it for this purpose. > > Or maybe the real experts on this stuff can tell me how wrong that is > and where it should go :) I don't believe anyone has implemented this before, so any experts would be self-appointed. Maybe this should be turned into a filesystem subject after all. The complexity comes from combining XIP with writes on the same chip. So solving your problem should be identical to solving the rw XIP filesystem problem. If there is interest in the latter, I'd offer my self-appointed expertise. Right, the solution to swap problem is identical to the rw XIP filesystem problem.Jörn, that's why you're the self-appointed subject matter expert! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Mon, 2 July 2007 10:44:00 -0700, Jared Hulbert wrote: > > >So what you mean is "swap on flash" ? Defintively sounds like an > >interesting topic, although I'm not too sure it's all that > >filesystem-related. > > Maybe not. Yet, it would be a very useful place to store data from a > file as a non-volatile page cache. > > Also it is something that I believe would benefit from a VFS-like API. > I mean there is a consistent interface a management layer like this > could use, yet the algorithms used to order the data and the interface > to the physical media may vary. There is no single right way to do > the management layer, much like filesystems. > > Given the page orientation of the current VFS seems to me like there > might be a nice way to use it for this purpose. > > Or maybe the real experts on this stuff can tell me how wrong that is > and where it should go :) I don't believe anyone has implemented this before, so any experts would be self-appointed. Maybe this should be turned into a filesystem subject after all. The complexity comes from combining XIP with writes on the same chip. So solving your problem should be identical to solving the rw XIP filesystem problem. If there is interest in the latter, I'd offer my self-appointed expertise. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
So what you mean is "swap on flash" ? Defintively sounds like an interesting topic, although I'm not too sure it's all that filesystem-related. Maybe not. Yet, it would be a very useful place to store data from a file as a non-volatile page cache. Also it is something that I believe would benefit from a VFS-like API. I mean there is a consistent interface a management layer like this could use, yet the algorithms used to order the data and the interface to the physical media may vary. There is no single right way to do the management layer, much like filesystems. Given the page orientation of the current VFS seems to me like there might be a nice way to use it for this purpose. Or maybe the real experts on this stuff can tell me how wrong that is and where it should go :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
> Christoph> So what you mean is "swap on flash" ? Defintively sounds > Christoph> like an interesting topic, although I'm not too sure it's > Christoph> all that filesystem-related. I wouldn't want to call it swap, as this carries with it block-io connotations. It's really mmap on flash. Yes it is really mmap on flash. But you are "swapping" pages from RAM to be mmap'ed on flash. Also the flash-io complexities are similar to the block-io layer. I think "swap on flash" is fair. Though that might be confused with making swap work on a NAND flash, which is very much like the current block-io approach. "Mmappable swap on flash" is more exact, I suppose. > You need either a block translation layer, Are you suggesting to go through the block layer to reach the flash? Well the obvious route would be to have this management layer use the MTD, I can't see anything wrong with that. > or a (swap) filesystem that > understands flash peculiarities in order to make such a thing work. > The standard Linux swap format will not work. Correct. BTW, you may want to have a look at my "[RFC] VM: I have a dream..." thread. Interesting. This idea does allow for swap to be access directly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
Christoph So what you mean is swap on flash ? Defintively sounds Christoph like an interesting topic, although I'm not too sure it's Christoph all that filesystem-related. I wouldn't want to call it swap, as this carries with it block-io connotations. It's really mmap on flash. Yes it is really mmap on flash. But you are swapping pages from RAM to be mmap'ed on flash. Also the flash-io complexities are similar to the block-io layer. I think swap on flash is fair. Though that might be confused with making swap work on a NAND flash, which is very much like the current block-io approach. Mmappable swap on flash is more exact, I suppose. You need either a block translation layer, Are you suggesting to go through the block layer to reach the flash? Well the obvious route would be to have this management layer use the MTD, I can't see anything wrong with that. or a (swap) filesystem that understands flash peculiarities in order to make such a thing work. The standard Linux swap format will not work. Correct. BTW, you may want to have a look at my [RFC] VM: I have a dream... thread. Interesting. This idea does allow for swap to be access directly. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
So what you mean is swap on flash ? Defintively sounds like an interesting topic, although I'm not too sure it's all that filesystem-related. Maybe not. Yet, it would be a very useful place to store data from a file as a non-volatile page cache. Also it is something that I believe would benefit from a VFS-like API. I mean there is a consistent interface a management layer like this could use, yet the algorithms used to order the data and the interface to the physical media may vary. There is no single right way to do the management layer, much like filesystems. Given the page orientation of the current VFS seems to me like there might be a nice way to use it for this purpose. Or maybe the real experts on this stuff can tell me how wrong that is and where it should go :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Mon, 2 July 2007 10:44:00 -0700, Jared Hulbert wrote: So what you mean is swap on flash ? Defintively sounds like an interesting topic, although I'm not too sure it's all that filesystem-related. Maybe not. Yet, it would be a very useful place to store data from a file as a non-volatile page cache. Also it is something that I believe would benefit from a VFS-like API. I mean there is a consistent interface a management layer like this could use, yet the algorithms used to order the data and the interface to the physical media may vary. There is no single right way to do the management layer, much like filesystems. Given the page orientation of the current VFS seems to me like there might be a nice way to use it for this purpose. Or maybe the real experts on this stuff can tell me how wrong that is and where it should go :) I don't believe anyone has implemented this before, so any experts would be self-appointed. Maybe this should be turned into a filesystem subject after all. The complexity comes from combining XIP with writes on the same chip. So solving your problem should be identical to solving the rw XIP filesystem problem. If there is interest in the latter, I'd offer my self-appointed expertise. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On 7/2/07, Jörn Engel [EMAIL PROTECTED] wrote: On Mon, 2 July 2007 10:44:00 -0700, Jared Hulbert wrote: So what you mean is swap on flash ? Defintively sounds like an interesting topic, although I'm not too sure it's all that filesystem-related. Maybe not. Yet, it would be a very useful place to store data from a file as a non-volatile page cache. Also it is something that I believe would benefit from a VFS-like API. I mean there is a consistent interface a management layer like this could use, yet the algorithms used to order the data and the interface to the physical media may vary. There is no single right way to do the management layer, much like filesystems. Given the page orientation of the current VFS seems to me like there might be a nice way to use it for this purpose. Or maybe the real experts on this stuff can tell me how wrong that is and where it should go :) I don't believe anyone has implemented this before, so any experts would be self-appointed. Maybe this should be turned into a filesystem subject after all. The complexity comes from combining XIP with writes on the same chip. So solving your problem should be identical to solving the rw XIP filesystem problem. If there is interest in the latter, I'd offer my self-appointed expertise. Right, the solution to swap problem is identical to the rw XIP filesystem problem.Jörn, that's why you're the self-appointed subject matter expert! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
[EMAIL PROTECTED] wrote: > > "Christoph" == Christoph Hellwig <[EMAIL PROTECTED]> writes: > > Christoph> On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert > > Christoph> wrote: > >> If you have a large array of a non-volatile semi-writeable memory > >> such as a highspeed NOR Flash or some of the similar emerging > >> technologies in a system. It would be useful to use that memory as > >> an extension of RAM. One of the ways you could do that is allow > >> pages to be swapped out to this memory. Once there these pages > >> could be read directly, but would require a COW procedure on a > >> write access. The reason why I think this may be a vm/fs topic is > >> that the hardware makes writing to this memory efficiently a > >> non-trivial operation that requires management just like a > >> filesystem. Also it seems to me that there are probably overlaps > >> between this topic and the recent filemap_xip.c discussions. > > Christoph> So what you mean is "swap on flash" ? Defintively sounds > Christoph> like an interesting topic, although I'm not too sure it's > Christoph> all that filesystem-related. I wouldn't want to call it swap, as this carries with it block-io connotations. It's really mmap on flash. > You need either a block translation layer, Are you suggesting to go through the block layer to reach the flash? > or a (swap) filesystem that > understands flash peculiarities in order to make such a thing work. > The standard Linux swap format will not work. Correct. BTW, you may want to have a look at my "[RFC] VM: I have a dream..." thread. Here is an excerpt: "What's more, there is no more swap. Apps are executed inplace, as if already loaded. Physical RAM is used to cache slower storage RAM, much the same as the CPU cache RAM caches slower physical RAM." The thread ended with this conclusion: Alan Cox wrote: > On Iau, 2006-02-02 at 21:59 +0300, Al Boldi wrote: > > So w/ 1GB RAM, no swap, and 1TB disk mmap'd, could this mmap'd space be > > added to the total memory available to the OS, as is done w/ swap? > > Yes in theory. It would be harder to manage. > > > And if that's possible, why not replace swap w/ mmap'd disk-space? > > Swap is just somewhere to stick data that isnt file backed, you could > build a swapless mmap based OS but it wouldn't be quite the same as > Unix/Linux are. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
Christoph Hellwig wrote: On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote: I'd like to see you there, so I hope we can find a date that most people are happy with. I'll try to start working that out after we have a rough idea of who's interested. Do we have any data preferences yet? You mean date? VM is arranged for the 3rd, IIRC Kernel summit doesn't start until the 5th, so there's a gap on the 4th if you want to sort out the fs stuff then? Not 100% sure on the dates. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
> "Christoph" == Christoph Hellwig <[EMAIL PROTECTED]> writes: Christoph> On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert Christoph> wrote: >> If you have a large array of a non-volatile semi-writeable memory >> such as a highspeed NOR Flash or some of the similar emerging >> technologies in a system. It would be useful to use that memory as >> an extension of RAM. One of the ways you could do that is allow >> pages to be swapped out to this memory. Once there these pages >> could be read directly, but would require a COW procedure on a >> write access. The reason why I think this may be a vm/fs topic is >> that the hardware makes writing to this memory efficiently a >> non-trivial operation that requires management just like a >> filesystem. Also it seems to me that there are probably overlaps >> between this topic and the recent filemap_xip.c discussions. Christoph> So what you mean is "swap on flash" ? Defintively sounds Christoph> like an interesting topic, although I'm not too sure it's Christoph> all that filesystem-related. You need either a block translation layer, or a (swap) filesystem that understands flash peculiarities in order to make such a thing work. The standard Linux swap format will not work. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Sat, Jun 30, 2007 at 06:02:44AM -0400, [EMAIL PROTECTED] wrote: > You need either a block translation layer, or a (swap) filesystem that > understands flash peculiarities in order to make such a thing work. > The standard Linux swap format will not work. Yes, it basically needs an ftl. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert wrote: > If you have a large array of a non-volatile semi-writeable memory such > as a highspeed NOR Flash or some of the similar emerging technologies > in a system. It would be useful to use that memory as an extension of > RAM. One of the ways you could do that is allow pages to be swapped > out to this memory. Once there these pages could be read directly, > but would require a COW procedure on a write access. The reason why I > think this may be a vm/fs topic is that the hardware makes writing to > this memory efficiently a non-trivial operation that requires > management just like a filesystem. Also it seems to me that there are > probably overlaps between this topic and the recent filemap_xip.c > discussions. So what you mean is "swap on flash" ? Defintively sounds like an interesting topic, although I'm not too sure it's all that filesystem-related. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote: > I'd like to see you there, so I hope we can find a date that most > people are happy with. I'll try to start working that out after we > have a rough idea of who's interested. Do we have any data preferences yet? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote: I'd like to see you there, so I hope we can find a date that most people are happy with. I'll try to start working that out after we have a rough idea of who's interested. Do we have any data preferences yet? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert wrote: If you have a large array of a non-volatile semi-writeable memory such as a highspeed NOR Flash or some of the similar emerging technologies in a system. It would be useful to use that memory as an extension of RAM. One of the ways you could do that is allow pages to be swapped out to this memory. Once there these pages could be read directly, but would require a COW procedure on a write access. The reason why I think this may be a vm/fs topic is that the hardware makes writing to this memory efficiently a non-trivial operation that requires management just like a filesystem. Also it seems to me that there are probably overlaps between this topic and the recent filemap_xip.c discussions. So what you mean is swap on flash ? Defintively sounds like an interesting topic, although I'm not too sure it's all that filesystem-related. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Sat, Jun 30, 2007 at 06:02:44AM -0400, [EMAIL PROTECTED] wrote: You need either a block translation layer, or a (swap) filesystem that understands flash peculiarities in order to make such a thing work. The standard Linux swap format will not work. Yes, it basically needs an ftl. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
Christoph == Christoph Hellwig [EMAIL PROTECTED] writes: Christoph On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert Christoph wrote: If you have a large array of a non-volatile semi-writeable memory such as a highspeed NOR Flash or some of the similar emerging technologies in a system. It would be useful to use that memory as an extension of RAM. One of the ways you could do that is allow pages to be swapped out to this memory. Once there these pages could be read directly, but would require a COW procedure on a write access. The reason why I think this may be a vm/fs topic is that the hardware makes writing to this memory efficiently a non-trivial operation that requires management just like a filesystem. Also it seems to me that there are probably overlaps between this topic and the recent filemap_xip.c discussions. Christoph So what you mean is swap on flash ? Defintively sounds Christoph like an interesting topic, although I'm not too sure it's Christoph all that filesystem-related. You need either a block translation layer, or a (swap) filesystem that understands flash peculiarities in order to make such a thing work. The standard Linux swap format will not work. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
Christoph Hellwig wrote: On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote: I'd like to see you there, so I hope we can find a date that most people are happy with. I'll try to start working that out after we have a rough idea of who's interested. Do we have any data preferences yet? You mean date? VM is arranged for the 3rd, IIRC Kernel summit doesn't start until the 5th, so there's a gap on the 4th if you want to sort out the fs stuff then? Not 100% sure on the dates. M. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
[EMAIL PROTECTED] wrote: Christoph == Christoph Hellwig [EMAIL PROTECTED] writes: Christoph On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert Christoph wrote: If you have a large array of a non-volatile semi-writeable memory such as a highspeed NOR Flash or some of the similar emerging technologies in a system. It would be useful to use that memory as an extension of RAM. One of the ways you could do that is allow pages to be swapped out to this memory. Once there these pages could be read directly, but would require a COW procedure on a write access. The reason why I think this may be a vm/fs topic is that the hardware makes writing to this memory efficiently a non-trivial operation that requires management just like a filesystem. Also it seems to me that there are probably overlaps between this topic and the recent filemap_xip.c discussions. Christoph So what you mean is swap on flash ? Defintively sounds Christoph like an interesting topic, although I'm not too sure it's Christoph all that filesystem-related. I wouldn't want to call it swap, as this carries with it block-io connotations. It's really mmap on flash. You need either a block translation layer, Are you suggesting to go through the block layer to reach the flash? or a (swap) filesystem that understands flash peculiarities in order to make such a thing work. The standard Linux swap format will not work. Correct. BTW, you may want to have a look at my [RFC] VM: I have a dream... thread. Here is an excerpt: What's more, there is no more swap. Apps are executed inplace, as if already loaded. Physical RAM is used to cache slower storage RAM, much the same as the CPU cache RAM caches slower physical RAM. The thread ended with this conclusion: Alan Cox wrote: On Iau, 2006-02-02 at 21:59 +0300, Al Boldi wrote: So w/ 1GB RAM, no swap, and 1TB disk mmap'd, could this mmap'd space be added to the total memory available to the OS, as is done w/ swap? Yes in theory. It would be harder to manage. And if that's possible, why not replace swap w/ mmap'd disk-space? Swap is just somewhere to stick data that isnt file backed, you could build a swapless mmap based OS but it wouldn't be quite the same as Unix/Linux are. Thanks! -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On 6/25/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: On Mon, Jun 25, 2007 at 05:08:02PM -0700, Jared Hulbert wrote: > -memory mappable swap file (I'm not sure if this one is appropriate > for the proposed meeting) Please explain what this is supposed to mean. If you have a large array of a non-volatile semi-writeable memory such as a highspeed NOR Flash or some of the similar emerging technologies in a system. It would be useful to use that memory as an extension of RAM. One of the ways you could do that is allow pages to be swapped out to this memory. Once there these pages could be read directly, but would require a COW procedure on a write access. The reason why I think this may be a vm/fs topic is that the hardware makes writing to this memory efficiently a non-trivial operation that requires management just like a filesystem. Also it seems to me that there are probably overlaps between this topic and the recent filemap_xip.c discussions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote: > Christoph Hellwig wrote: > >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'd like to see you there, so I hope we can find a date that most > people are happy with. I'll try to start working that out after we > have a rough idea of who's interested. I'm game, but won't be staying past the end of KS (I'll arrive Sept 2nd or so though). Given debates so far, it probably makes sense to talk about things at KS too. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Mon, Jun 25, 2007 at 05:08:02PM -0700, Jared Hulbert wrote: > -memory mappable swap file (I'm not sure if this one is appropriate > for the proposed meeting) Please explain what this is supposed to mean. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Mon, Jun 25, 2007 at 05:08:02PM -0700, Jared Hulbert wrote: -memory mappable swap file (I'm not sure if this one is appropriate for the proposed meeting) Please explain what this is supposed to mean. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote: Christoph Hellwig wrote: 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'd like to see you there, so I hope we can find a date that most people are happy with. I'll try to start working that out after we have a rough idea of who's interested. I'm game, but won't be staying past the end of KS (I'll arrive Sept 2nd or so though). Given debates so far, it probably makes sense to talk about things at KS too. -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On 6/25/07, Christoph Hellwig [EMAIL PROTECTED] wrote: On Mon, Jun 25, 2007 at 05:08:02PM -0700, Jared Hulbert wrote: -memory mappable swap file (I'm not sure if this one is appropriate for the proposed meeting) Please explain what this is supposed to mean. If you have a large array of a non-volatile semi-writeable memory such as a highspeed NOR Flash or some of the similar emerging technologies in a system. It would be useful to use that memory as an extension of RAM. One of the ways you could do that is allow pages to be swapped out to this memory. Once there these pages could be read directly, but would require a COW procedure on a write access. The reason why I think this may be a vm/fs topic is that the hardware makes writing to this memory efficiently a non-trivial operation that requires management just like a filesystem. Also it seems to me that there are probably overlaps between this topic and the recent filemap_xip.c discussions. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Jun 26, 2007 12:35 +1000, Nick Piggin wrote: > Leaving my opinion of higher order pagecache aside, this _may_ be an > example of something that doesn't need a lot of attention, because it > should be fairly uncontroversial from a filesystem's POV? (eg. it is > more a relevant item to memory management and possibly block layer). > OTOH if it is discussed in the context of "large blocks in the buffer > layer is crap because we can do it with higher order pagecache", then > that might be interesting :) FWIW, being able to have large (8-64kB) blocksize would be great for ext2/3/4. We'd sort of been betting on this by limiting the on-disk extent format to 48-bit physical block numbers, and to have 2 patches to implement this in as many weeks is excellent. To me the mechanism doesn't matter, whether through fsblock or high-order PAGE_SIZE. I'll let the rest of you duke it out as long as at least one of them makes it into the kernel. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
Christoph Hellwig wrote: 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'd like to see you there, so I hope we can find a date that most people are happy with. I'll try to start working that out after we have a rough idea of who's interested. 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? I'll just cc Martin, however the VM conference I think is pretty short on filesystem people. I'd also like to avoid a lot of VM topics and hopefully have enough time for a topic of interest or so from each fs maintainer who has something to talk about. But I'm open to ideas that will make it work better. FWIW, Anton has offered to try arranging conference facilities at the university, so I think we should be covered there. - 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. Leaving my opinion of higher order pagecache aside, this _may_ be an example of something that doesn't need a lot of attention, because it should be fairly uncontroversial from a filesystem's POV? (eg. it is more a relevant item to memory management and possibly block layer). OTOH if it is discussed in the context of "large blocks in the buffer layer is crap because we can do it with higher order pagecache", then that might be interesting :) Anyway, I won't say no to any proposal, so keep the ideas coming. We can talk about whatever we find interesting on the day. - how to make complex API changes without having to fix most things yourself. More issues: Thanks Christoph, sounds good. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
A few things I'd like to talk about are: - 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 - how to make complex API changes without having to fix most things yourself. I'd like to add: -revamping filemap_xip.c -memory mappable swap file (I'm not sure if this one is appropriate for the proposed meeting) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
> > 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). Yeah, I'd be interested. > More issues: - chris mason's patches to normalize buffered and direct locking - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
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). Yeah, I'd be interested. More issues: - chris mason's patches to normalize buffered and direct locking - z - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
A few things I'd like to talk about are: - 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 - how to make complex API changes without having to fix most things yourself. I'd like to add: -revamping filemap_xip.c -memory mappable swap file (I'm not sure if this one is appropriate for the proposed meeting) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
Christoph Hellwig wrote: 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'd like to see you there, so I hope we can find a date that most people are happy with. I'll try to start working that out after we have a rough idea of who's interested. 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? I'll just cc Martin, however the VM conference I think is pretty short on filesystem people. I'd also like to avoid a lot of VM topics and hopefully have enough time for a topic of interest or so from each fs maintainer who has something to talk about. But I'm open to ideas that will make it work better. FWIW, Anton has offered to try arranging conference facilities at the university, so I think we should be covered there. - 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. Leaving my opinion of higher order pagecache aside, this _may_ be an example of something that doesn't need a lot of attention, because it should be fairly uncontroversial from a filesystem's POV? (eg. it is more a relevant item to memory management and possibly block layer). OTOH if it is discussed in the context of large blocks in the buffer layer is crap because we can do it with higher order pagecache, then that might be interesting :) Anyway, I won't say no to any proposal, so keep the ideas coming. We can talk about whatever we find interesting on the day. - how to make complex API changes without having to fix most things yourself. More issues: Thanks Christoph, sounds good. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm/fs meetup in september?
On Jun 26, 2007 12:35 +1000, Nick Piggin wrote: Leaving my opinion of higher order pagecache aside, this _may_ be an example of something that doesn't need a lot of attention, because it should be fairly uncontroversial from a filesystem's POV? (eg. it is more a relevant item to memory management and possibly block layer). OTOH if it is discussed in the context of large blocks in the buffer layer is crap because we can do it with higher order pagecache, then that might be interesting :) FWIW, being able to have large (8-64kB) blocksize would be great for ext2/3/4. We'd sort of been betting on this by limiting the on-disk extent format to 48-bit physical block numbers, and to have 2 patches to implement this in as many weeks is excellent. To me the mechanism doesn't matter, whether through fsblock or high-order PAGE_SIZE. I'll let the rest of you duke it out as long as at least one of them makes it into the kernel. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
vm/fs meetup in september?
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 was thinking about trying to arrange a proper mini summit thing, but it's a bit difficult and we could talk this year about doing it for subsequent years. If there is a bit of interest, we could probably find a small room somewhere this year on pretty short notice or do it as a BOF or something. 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. A few things I'd like to talk about are: - 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 - how to make complex API changes without having to fix most things yourself. Anyway, if you will be in the area and are interested, let me know (off list) and we can work out time and place. Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
vm/fs meetup in september?
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 was thinking about trying to arrange a proper mini summit thing, but it's a bit difficult and we could talk this year about doing it for subsequent years. If there is a bit of interest, we could probably find a small room somewhere this year on pretty short notice or do it as a BOF or something. 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. A few things I'd like to talk about are: - 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 - how to make complex API changes without having to fix most things yourself. Anyway, if you will be in the area and are interested, let me know (off list) and we can work out time and place. Thanks, Nick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
