query regarding inode pages

[piyush moghe]

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 <shubham20006 at gmail.com>wrote:

> Hi Joel,
>
> On Wed, Jul 13, 2011 at 9:28 PM, Joel A Fernandes <agnel.joel at gmail.com>
> 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 <shubham20006 at gmail.com>
> 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110714/c554a968/attachment-0001.html