Re: [lc-devel] WKdm to kernel mode
Status: Beta
Brought to you by:
nitin_sf
From: Nitin G. <nit...@gm...> - 2006-04-26 11:16:55
|
Hello Scott Kaplan, > >> Currently I have some problem getting timing information >> needed to see how much time de/compress() is taking. > > Can't you turn off power-saving CPU features and use rdtscll()? > I was trying get_jiffies_64() following how printk() gets timing info when kernel debugging is turned on. Surprisingly, I was getting same time before and after compress() even when it gives time in nanoseconds -- so there's is certainly some kind of problem with how I'm using it. I will now try your suggestion. >> I was just thinking to bring down temp buffers to <4k >> so that I can de/allocate single (0 order) page for these buffers. > > Why not allocate them statically? Then you don't have to do the work of > allocating and freeing even these 0-order pages. Even if it is fast, > it's going to be frequently repeated work that can easily be avoided. > In any case, either approach is going to be better than kmalloc/kfree. > Static allocation will require calls to compress() to be serialized using locks since same allocated buffer space will be used for each call. This will prevent more than one compress() to happen simultaneously like: compress (page 1) { lock temp_buffers() --- pre-emt ---- compress (page 2) { wait for lock on buffers() do some work() unlock temp_buffers() } // got lock do some work() unlock temp_buffers() } This waiting for lock is not required if these buffers are dynamically allocated since then each call will have separate buffer space to work in. Isn't static allocation a special case of global allocation where variable name is hidden in function scope? Is there any other difference in static/global? Best Regards, Nitin |