[Beowulf] Racing kernels

Sebastien Cabaniols sebastien.cabaniols at hp.com
Tue Apr 5 09:00:00 EDT 2005


On Tuesday 05 April 2005 14:00, Ashley Pittman wrote:
> On Tue, 2005-04-05 at 06:06 -0400, Robert G. Brown wrote:most of
>
> > what the kernel actually does is run the scheduler.  In numerical code
> > the kernel can be pretty much irrelevant, as long as it isn't openly
> > inefficient.  Like 99%+ of your CPU goes to the computation, no matter
> > what you do tweaking the kernel.  Where kernel optimization helps is if
> > the application USES parts of the kernel a LOT.  Then making small
> > changes in that branch that make it run more efficient can really
> > matter.
>
> I'm with Robert on this one, the kernel doesn't actually do a lot so
> it's hard to see what CPU cycles any "optimisation" are going to free
> up.  Maybe the filesystem code has to do some work now and then but
> choosing the right module to use here is key, not removing the ones you
> aren't using.
>
> The filesystem cache however can use a lot of memory, particularly after
> the nightly "updatedb" cron session.  Much better to try and restrict
> the size of your filesystem and remove all the cron entries (if ram is
> an issue).

Assuming your code is fitting the machine you are running on ( so obviously no 
swapping or less obvious an interconnect fast enough to match the grain of 
your application) finding a better algorithm to solve your problem is your 
best chance. 

I would say simply, a fast kernel is an _unused_ kernel and in HPC benchmark, 
except when we do heavy IO on  very fast storage, we don't spend cycles in 
the kernel path. I tried to measure a few years ago the impact of decreasing 
the interrupt rate from 500Hz (talking scheduler timer) to 50 Hz, this was 
wasted time.

by changing the algorithm I don't only mean changing the complexity of the 
code, I also mean adapting to the new (since five years) constraints of HPC 
computing: the mismatch between the speed of the CPU and the 
latency/bandwidth of the memory. So right now we are using a lot of our time 
doing (1) prefetch, (2) prefetch and (3) prefetch.



sebastien
 


>
> Ashley,
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list