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@xxxxxxxxx> wrote:
Hi Joel,
I don't know about the bdflush daemon, but I guess that pdflush daemon
On Wed, Jul 13, 2011 at 9:28 PM, Joel A Fernandes <agnel.joel@xxxxxxxxx> 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?
has been superseded in recent kernel. I am working on 2.6.18 kernel.
Yes you got it correct. I want to protect my filesystem against low
>
> On Wed, Jul 13, 2011 at 10:45 AM, shubham sharma <shubham20006@xxxxxxxxx> 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.
memory conditions.
Thanks for the lead. I will dig in that now.
>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
>
Thanks,
Shubham
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
