[linuxkernelnewbies] Advanced XIP filesystem

[Peter Teoh]

Advanced XIP filesystem 7 messages Peter Teoh <htmldevelo...@gmail.com> Wed, Feb 18, 2009 at 12:38 AM To: jare...@gmail.com I read with interest your OLS2008 papers.   But I have some doubts: I was not able to fully comprehend your problem of "no struct page for mm/filemap_xip.c" what is the purpose of filemap_xip.c?      filemap.c as i understood is for pagecache implementation correct?   so what about filemap_xip.c?  pagecaching on the xip filesystem?   if so then what is the purpose of struct page?   the memory structure that hold the cache implementation?   so basically filemap_xip.c's purpose is to build up a pagetable representing all the individual struct pages that mapped to the xip filesystem right? in your paper u mention xip files vs non-xip files....do u mean to say files stored in the normal pagecache implementation, vs files stored in the pagecache implementation of xip-filesystem? thank you for the clarification. -- Regards, Peter Teoh Jared Hulbert <jare...@gmail.com> Wed, Feb 18, 2009 at 11:53 AM To: Peter Teoh <htmldevelo...@gmail.com> Are you just curious or do you have a need for this kind of solution? > I was not able to fully comprehend your problem of "no struct page for > mm/filemap_xip.c" > > what is the purpose of filemap_xip.c?      filemap.c as i understood is for > pagecache implementation correct?   so what about filemap_xip.c? > pagecaching on the xip filesystem?   if so then what is the purpose of > struct page?   the memory structure that hold the cache implementation?   so > basically filemap_xip.c's purpose is to build up a pagetable representing > all the individual struct pages that mapped to the xip filesystem right? filemap_xip.c has existed since ~2.6.12 I think, so it isn't something unique to AXFS.  I only had to alter the functionality a bit. The purpose of filemap_xip.c is to allow XIP filesystems to bypass the normal pagecache flow and give applications direct access to the device memory. > in your paper u mention xip files vs non-xip files....do u mean to say files > stored in the normal pagecache implementation, vs files stored in the > pagecache implementation of xip-filesystem? yes.  XIP files/pages do not get copied to a page cache in RAM, they are are used 'In Place' meaning the are used from the same device, address that they are stored at.  Most filesystems expect data to be stored on a block device that doesn't have a memory interface.  If the data is stored on something with a memory interface, like a RAM or a NOR flash, then why copy it to RAM?  That would be a waste of time and space. Peter Teoh <htmldevelo...@gmail.com> Wed, Feb 18, 2009 at 9:32 PM To: Jared Hulbert <jare...@gmail.com> thank you for the explanation.   [Quoted text hidden] yes, i always thought that flash are just memory for the CPU, but did not know that internally, the CPU cannot really access the the contents on the flash just like memory connected to the north-south bridge does.   perhaps they had to go through the I/O controller, or south bridge (http://en.wikipedia.org/wiki/Southbridge_(computing)), which account for the need for software intermediation.    but no matter what, bottom line is that talking to the external devices is always either I/O ports, or DMA - so assuming that the flash is going via I/O ports, which means that filemap_xip.c necessarily have to access these external devices as and when it is needed/executed....ie, essentially:         err = mapping->a_ops->get_xip_mem(mapping, index, 0,                                                 &xip_mem, &xip_pfn); this will extract the data from the external device via traditional method, then copy the data to xip_mem, which is still normal RAM storing the FLASH content, block-by-block basis, right? thanks for sharing with a newbie :-)..... -- Regards, Peter Teoh Jared Hulbert <jare...@gmail.com> Thu, Feb 19, 2009 at 3:57 PM To: Peter Teoh <htmldevelo...@gmail.com> > thank you for the explanation. no prob > yes, i always thought that flash are just memory for the CPU, but did not > know that internally, the CPU cannot really access the the contents on the > flash just like memory connected to the north-south bridge does.   perhaps > they had to go through the I/O controller, or south bridge > (http://en.wikipedia.org/wiki/Southbridge_(computing)), which account for > the need for software intermediation. Ahh well it's not that simple.  See for NOR type flashes on an embedded processor you can talk to them just like a RAM.  Writing to them is also a memory operation.  However to get data _programmed_ into it requires that you _write_ commands then data to the flash and then read the flash to check for program completion with a special register bit you read from the the flash. NAND flashes are not really memory devices at all they are really more like block devices.  So you treat them like IO. PC's don't support this functionality yet. > but no matter what, bottom line is that talking to the external devices is > always either I/O ports, or DMA - so assuming that the flash is going via > I/O ports, which means that filemap_xip.c necessarily have to access these > external devices as and when it is needed/executed....ie, essentially: > >         err = mapping->a_ops->get_xip_mem(mapping, index, 0, >                                                 &xip_mem, &xip_pfn); > > this will extract the data from the external device via traditional method, > then copy the data to xip_mem, which is still normal RAM storing the FLASH > content, block-by-block basis, right? No.  For hardware that supports get_xip_mem() the xip_mem is a pointer to the actual Flash memory.  That is the esscence of XIP (eXecute In Place) meaning we use the data where it is stored on Flash.  If you can't do a memory access directly from the Flash, this code can't be used on that hardware. Peter Teoh <htmldevelo...@gmail.com> Thu, Feb 19, 2009 at 11:49 PM To: Jared Hulbert <jare...@gmail.com> thank you that was very useful info.   hope to read further in near future...... [Quoted text hidden] -- Regards, Peter Teoh Peter Teoh <htmldevelo...@gmail.com> Fri, Feb 20, 2009 at 1:34 AM To: Jared Hulbert <jare...@gmail.com> a question still lingers.....all seemingly related: a.   I found this function: /*  * __xip_unmap is invoked from xip_unmap and  * xip_write  *  * This function walks all vmas of the address_space and unmaps the  * __xip_sparse_page when found at pgoff.  */ static void __xip_unmap (struct address_space * mapping,                     unsigned long pgoff) {        struct vm_area_struct *vma;        struct mm_struct *mm; but cannot really explain why xip_mmap() does not exists?   Who is the one that setup the VMA addresses pointing to the flash area? The only part I can find doing this is xip_file_fault().   Correct? and xip_file_fault() is called from __do_fault()....which subsequently then called:        ret = vma->vm_ops->fault(vma, &vmf);        if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE)))                return ret; and the fault() dynamic pointer is pointing at xip_file_fault() in our case....correct? b.   but even more deeper, is the question of who/how is the pagetable setup for pointing at the flash memory directly.....as u know....the prerequisites of all MMU operation.   so do u know which is the function used for setting up the pagetable .....necessarily arch-dependent, as it is CPU specifics.... c.   I noticed this pattern:   344                         mutex_lock(&xip_sparse_mutex);    345                         status = a_ops->get_xip_mem(mapping, index, 1,    346 &xip_mem, &xip_pfn);    347                         mutex_unlock(&xip_sparse_mutex); so question is why the mutex lock?   normally inside the hardware mm fault handler, all interrupts are disabled, and so rescheduling to another process, or being interrupted, is not possible.   so...what about xip_file_fault()....it definitely is not executing under non-preemptible mode.   who is the caller of xip_file_fault? d.   but then why sometimes there is no locking? for eg: mm/filemap.c:do_xip_mapping_read():                error = mapping->a_ops->get_xip_mem(mapping, index, 0,                                                        &xip_mem, &xip_pfn);                if (unlikely(error)) {                        if (error == -ENODATA) {                                /* sparse */                                zero = 1;                        } else                                goto out; ? [Quoted text hidden] -- Regards, Peter Teoh Jared Hulbert <jare...@gmail.com> Fri, Feb 20, 2009 at 2:17 AM To: Peter Teoh <htmldevelo...@gmail.com> > but cannot really explain why xip_mmap() does not exists? it does!  xip_file_mmap() > Who is the > one that setup the VMA addresses pointing to the flash area? vm_insert_pfn() or vm_insert_mixed() > The only part I can find doing this is xip_file_fault().   Correct? > and xip_file_fault() is called from __do_fault()....which subsequently > then called: > >        ret = vma->vm_ops->fault(vma, &vmf); >        if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE))) >                return ret; > > and the fault() dynamic pointer is pointing at xip_file_fault() in our > case....correct? > > b.   but even more deeper, is the question of who/how is the pagetable > setup for pointing at the flash memory directly.....as u know....the > prerequisites of all MMU operation.   so do u know which is the > function used for setting up the pagetable .....necessarily > arch-dependent, as it is CPU specifics.... again vm_insert_mixed() > c.   I noticed this pattern: > >   344                         mutex_lock(&xip_sparse_mutex); >    345                         status = a_ops->get_xip_mem(mapping, index, 1, >    346 > &xip_mem, &xip_pfn); >    347                         mutex_unlock(&xip_sparse_mutex); > > so question is why the mutex lock?   normally inside the hardware mm > fault handler, all interrupts are disabled, and so rescheduling to > another process, or being interrupted, is not possible.   so...what > about xip_file_fault()....it definitely is not executing under > non-preemptible mode.   who is the caller of xip_file_fault? no idea. > d.   but then why sometimes there is no locking? > > for eg: > > mm/filemap.c:do_xip_mapping_read(): > > >                error = mapping->a_ops->get_xip_mem(mapping, index, 0, >                                                        &xip_mem, &xip_pfn); >                if (unlikely(error)) { >                        if (error == -ENODATA) { >                                /* sparse */ >                                zero = 1; >                        } else >                                goto out; > > ? no idea. You ought to start posting this stuff to LKML.  These are good questions, and this stuff is really only understood by like 2 guys.