Re: how to flush cache ??

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



sorry i have lots of questions for you too!!!!

On Sat, Jul 18, 2009 at 2:16 PM, er krishna<erkrishna@xxxxxxxxx> wrote:
> Peter,
>
> 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 ????
>

to answer the question above, u need to know what is
proc_dointvec_minimax() doing....which i don't.   and when the
following drop_caches_sysctl_handler() is called, what are all the
different parameters like ctl_table etc....?   have it been
mutex-locked or does it not exists?   and what does user buffer
correspond to???? i am not sure....

 64
 65 int drop_caches_sysctl_handler(ctl_table *table, int write,
 66         struct file *file, void __user *buffer, size_t *length,
loff_t *ppos    )
 67 {
 68         proc_dointvec_minmax(table, write, file, buffer, length, ppos);
 69         if (write) {
 70                 if (sysctl_drop_caches & 1)
 71                         drop_pagecache();
 72                 if (sysctl_drop_caches & 2)
 73                         drop_slab();
 74         }

these are the issues u have to understand....and very deeply if u want
to do it in the kernel.....

but generally the truth is this:   the higher level the kernel API
(assuming they are organized hierarchically)....the easier the API to
use....and more stable your kernel module is.

good luck!!!

>
> 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
>>
>> 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?
>> >
>>
>> but if u insist on doing it in kernel u HAVE TO WORRY about lots of
>> things:
>>
>> 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
>
>



-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux