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