[Beowulf] big read triggers migration and slow memory IO? [bcc - adr][faked - adr]

[John Hearns]

> I wonder if they might not be developing this on a system with a relatively small amount of memory per zone, like 16 or 32GB, and the method just doesn't scale > well to 262GB/node.

> Also the compaction would seem to be a lost cause at the times it was running on my system, because there were very few free pages.  (What it needed to do, > but wasn't, was throw pages out of file cache.)  I'm thinking that under those conditions compation would work about as well as a disk defragmentation on a > > > hard drive that is 99% full.

I think you have a point.   I am not going to put this very well, and apologies to all Linux kernel developers.
In the past I have felt like the Linux kernel is developed for desktop use - priority being given to speed of response for interactive applications.
I am probably very wrong these days as there are lots of developers from big companies.


Also the setting for "min_free_kbytes" is worth looking at on systems with 2.6 series kernels.
The default value is stupidly low.
I just checked on two systems:

2.6.32 kernel   vm.min_free_kbytes = 90112
3.10.0 kernel  vm.min_free_kbytes = 262144  (much better)




In my last job I worked with SuSE desktop systems which engineers were using. They were finding systems becoming horribly unresponsive when under load of reading/writing files. I altered the swappiness and the min_free_kbytes and made the systems a good deal more useable.

Also recently I have worked on two clusters which were installed with 10 gigabit Ethernet, and NFS servers on head node.
The users complained that the head nodes were crashing, and had to be powered off and on to reset them.
My suspicion was that the systems were 'paging themselves into the deck' under IO loads.
Configuring Jumbo frames, plus TCP stack tunings and setting min_free_kbytes higher solved the problem, and users happy!

So in short - also whack up min_free_kbytes which I think might help leave some free room for the above compaction algorithm too.


#####################################################################################
Scanned by MailMarshal - M86 Security's comprehensive email content security solution.
#####################################################################################
Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Employees of XMA Ltd are expressly required not to make defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned. The company will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising. XMA Limited is registered in England and Wales (registered no. 2051703). Registered Office: Wilford Industrial Estate, Ruddington Lane, Wilford, Nottingham, NG11 7EP