Re: query regarding inode pages
I think you can mark the pages as PG_unevictable to let the inode pages
remain mapped always.
OR
You can also set AS_UNEVICTABLE flag bit on whole address space mapping of
inode. Please refer following code:
static inline void mapping_set_unevictable(struct address_space *mapping)
{
set_bit(AS_UNEVICTABLE, &mapping->flags);
}
This code is used to mark all inode pages ( i.e complete address space
mapping) as unevictable.
On Wed, Jul 13, 2011 at 9:48 PM, shubham sharma wrote:
> Hi Joel,
>
> On Wed, Jul 13, 2011 at 9:28 PM, Joel A Fernandes
> wrote:
> > [CC'ing list]
> >
> > Hi Shubham,
> >
> > I am not very familiar with the code for pdflush. But wasn't it
> > superseded by bdflush (or similar) in recent kernels?
>
> I don't know about the bdflush daemon, but I guess that pdflush daemon
> has been superseded in recent kernel. I am working on 2.6.18 kernel.
>
> >
> > On Wed, Jul 13, 2011 at 10:45 AM, shubham sharma
> wrote:
> >> I am trying to write a memory based file system. The file system is
> >> intended to create files/directories and write their contents only on
> >> pages. For this I have used the function grab_cache_page() function to
> >> get a new locked page in case the page does not exists in the radix
> >> tree of the inode.
> >>
> >> As the filesystem is memory based and all the data exists only on the
> >> memory, so I don't release the lock on the page as I fear that the
> >> pdflush daemon can swap out the pages on which I have written data and
> >> I may never see that data again. I unlock all the pages of all the
> >> inodes of the file system in the kill_sb function once the file system
> >> is being unmounted. But the problem I am facing is that if I open a
> >> file in which I have already written something (and its pages are
> >> locked), the open system call in turn calls the __lock_page() function
> >> which waits for the pages belonging to the inode to get unlocked.
> >> Hence the system call stalls indefinitely. I want to know if there is
> >> a mechanism by which I can prevent the pdflush daemon from swapping
> >> the pages that my filesystem refers to??
> >
> > I'm not sure if pdflush is what "swaps" pages? Isn't that the role of
> > kswapd? pdflush AFAIK just writes dirty pages back to the backing
> > device.
> >
> > I think what you're referring to is a certain page replacement
> > behavior in low memory conditions that you want to protect your
> > filesystem against.
>
> Yes you got it correct. I want to protect my filesystem against low
> memory conditions.
>
> >I will be interested in responses from others
> > about this, and will dig into the code during off office hours.
> >
> > Maybe tmpfs is a good reference for your work?
>
> Thanks for the lead. I will dig in that now.
> >
> > Thanks,
> > Joel
> >
> Thanks,
> Shubham
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: query regarding inode pages
Hi Joel, On Wed, Jul 13, 2011 at 9:28 PM, Joel A Fernandes wrote: > [CC'ing list] > > Hi Shubham, > > I am not very familiar with the code for pdflush. But wasn't it > superseded by bdflush (or similar) in recent kernels? I don't know about the bdflush daemon, but I guess that pdflush daemon has been superseded in recent kernel. I am working on 2.6.18 kernel. > > On Wed, Jul 13, 2011 at 10:45 AM, shubham sharma > wrote: >> I am trying to write a memory based file system. The file system is >> intended to create files/directories and write their contents only on >> pages. For this I have used the function grab_cache_page() function to >> get a new locked page in case the page does not exists in the radix >> tree of the inode. >> >> As the filesystem is memory based and all the data exists only on the >> memory, so I don't release the lock on the page as I fear that the >> pdflush daemon can swap out the pages on which I have written data and >> I may never see that data again. I unlock all the pages of all the >> inodes of the file system in the kill_sb function once the file system >> is being unmounted. But the problem I am facing is that if I open a >> file in which I have already written something (and its pages are >> locked), the open system call in turn calls the __lock_page() function >> which waits for the pages belonging to the inode to get unlocked. >> Hence the system call stalls indefinitely. I want to know if there is >> a mechanism by which I can prevent the pdflush daemon from swapping >> the pages that my filesystem refers to?? > > I'm not sure if pdflush is what "swaps" pages? Isn't that the role of > kswapd? pdflush AFAIK just writes dirty pages back to the backing > device. > > I think what you're referring to is a certain page replacement > behavior in low memory conditions that you want to protect your > filesystem against. Yes you got it correct. I want to protect my filesystem against low memory conditions. >I will be interested in responses from others > about this, and will dig into the code during off office hours. > > Maybe tmpfs is a good reference for your work? Thanks for the lead. I will dig in that now. > > Thanks, > Joel > Thanks, Shubham ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: query regarding inode pages
[CC'ing list] Hi Shubham, I am not very familiar with the code for pdflush. But wasn't it superseded by bdflush (or similar) in recent kernels? On Wed, Jul 13, 2011 at 10:45 AM, shubham sharma wrote: > I am trying to write a memory based file system. The file system is > intended to create files/directories and write their contents only on > pages. For this I have used the function grab_cache_page() function to > get a new locked page in case the page does not exists in the radix > tree of the inode. > > As the filesystem is memory based and all the data exists only on the > memory, so I don't release the lock on the page as I fear that the > pdflush daemon can swap out the pages on which I have written data and > I may never see that data again. I unlock all the pages of all the > inodes of the file system in the kill_sb function once the file system > is being unmounted. But the problem I am facing is that if I open a > file in which I have already written something (and its pages are > locked), the open system call in turn calls the __lock_page() function > which waits for the pages belonging to the inode to get unlocked. > Hence the system call stalls indefinitely. I want to know if there is > a mechanism by which I can prevent the pdflush daemon from swapping > the pages that my filesystem refers to?? I'm not sure if pdflush is what "swaps" pages? Isn't that the role of kswapd? pdflush AFAIK just writes dirty pages back to the backing device. I think what you're referring to is a certain page replacement behavior in low memory conditions that you want to protect your filesystem against. I will be interested in responses from others about this, and will dig into the code during off office hours. Maybe tmpfs is a good reference for your work? Thanks, Joel ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
query regarding inode pages
I am trying to write a memory based file system. The file system is intended to create files/directories and write their contents only on pages. For this I have used the function grab_cache_page() function to get a new locked page in case the page does not exists in the radix tree of the inode. As the filesystem is memory based and all the data exists only on the memory, so I don't release the lock on the page as I fear that the pdflush daemon can swap out the pages on which I have written data and I may never see that data again. I unlock all the pages of all the inodes of the file system in the kill_sb function once the file system is being unmounted. But the problem I am facing is that if I open a file in which I have already written something (and its pages are locked), the open system call in turn calls the __lock_page() function which waits for the pages belonging to the inode to get unlocked. Hence the system call stalls indefinitely. I want to know if there is a mechanism by which I can prevent the pdflush daemon from swapping the pages that my filesystem refers to?? What limited knowledge I have on pdflush daemon, I guess that the daemon searches for the dirty inodes in the list maintained per super block. So if I remove all the inodes from this list (or not add any of my inodes I create in the list), will I be able to prevent the daemon from flushing data from my file system? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
