Thats' fine. I have already gone through those articles, and user space techniques are fine with me. But here I have to do it
( flush the cache ) from kernel module, so I have to do all the things that kernel does when it get argument 3 into /proc/sys/vm/dropcaches.
Now again drop_caches_sysctl_handler function accepts lots of argument and its not defined in .h file, so what I have to do is, I have to pass those arguments to this function and include it in my module by exporting this function. This is a bit of cumbersome and I really don't know weather it will work or not !!!!!
Just asking, if I export only drop_pagecache function and add it in my module, it will work or not. Or, any other better way to handle this case from kernel module ????
Thanks & Best Regards,
Krishna
On Sat, Jul 18, 2009 at 11:12 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
my first attempt at any solution, is to do it in userspace. This
article is good:
http://aplawrence.com/Linux/buffer_cache.html
drop caches is principally used, if u want to remove all existing
cache, not flushing it to the storage, so that your next read is
guaranteed to be from the storage. but if u want to flush to
storage, "sync" is the better option.
Many advices are available on the use of drop_cache:
http://jons-thoughts.blogspot.com/2007/09/tip-of-day-dropcaches.html
http://linux-mm.org/Drop_Caches
http://jons-thoughts.blogspot.com/2007/09/tip-of-day-dropcaches.html
http://www.linuxreaders.com/tag/drop_caches/
http://ubuntuforums.org/showthread.php?t=1002612
but if u insist on doing it in kernel u HAVE TO WORRY about lots of things:
On Sat, Jul 18, 2009 at 12:02 AM, er krishna<erkrishna@xxxxxxxxx> wrote:
> Dear Peter,
>
> Thanks for the great help.
>
> Just asking, If I have to include this function [ drop_caches_sysctl_handler
> ] , then what should I do ? Shall I export it and compile the kernel or is
> there any other means to do it.
>
> Second, I just want to know that there will be lots of hurdels to set the
> arguments of above handler, So, if I only export
> static void drop_pagecache(void) function in kernel & include this in my
> driver, would it work as per the expectation ?
>
> May be I am wrong, but please correct if the above method need any
> modification?
>
a. what if u are interrupted by hardware/software interrupt? if u
cannot tolerate interrupt, then u may need to disable interrupt. but
then u have to understand the serious implication of these as well.
b. does ANY of the API u are going to call, require any non-blocking
condition? or will it result in blocking condition?
c. since u are doing it in kernel - how do u ensure that the same is
not called by two different CPU at the same time? or, how do u
ensure that the SAME cpu don't execute the same function, in a nested
manner - assuming interrupt is enabled, and the same function got
executed during the 2nd interrupt?
lots of small little things to worry about, if not, it will result in
kernel crash, or system deadlock.....consequences may result in lost
of human life....
for example, even kernel developer had bugs in this API before:
http://forum.soft32.com/linux/circular-locking-proc-sys-vm-drop_caches-ftopict340340.html
--
> Thanks & Best regards,
> Krishna
>
>
>
>
>
>
> On Fri, Jul 17, 2009 at 8:11 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
>>
>> sorry....my previous was accidentally sent out halfway...specifically
>> detailing on the implementation of drop_caches_sysctl_handler():
>>
>> > and reading into the implementation, it just wipe away all the dirty
>> > buffer cache (as the name implies). Not really the type of flushing
>> > I originally meant - which is to write back the dirty buffer cache to
>> > the backing store.
>> >
>> drop_caches_sysctl_handler()--->
>> drop_pagecache()--->drop_pagecache_sb()--->invalidate_mapping_pages().
>>
>> where invalidate_mappping_pages() is in mm/truncate.c.....and so on.
>>
>> and as drop_pagecache_sb() is done for each filesystem's superblock,
>> which is why my initial statement is that it is performance-heavy.
>> if u know what to flush out, doing it directly will be much better.
>
>
Regards,
Peter Teoh
