<snip> > I read that [3] article and the first two things I noticed were the > reference to "small RAM" which in the days of $11/GB RAM is rare, and > that the author didn't touch the "dirty" tuning parameters, which are > better suited to controlling the behavior of i/o buffers. He didn't > mention tuning read ahead to speed reading of application off the > disk (which limits response even if lots of memory is free). In short > the article is based on one trick, not a balanced approach to getting > both responsive performance and good i/o performance. > > I regularly handle images 4x the size of memory, and in 33 days uptime > have written a total of 109MB (from iostat) to swap. A balanced tune > is far nicer than cranking swappiness as low as it will go and keeping > crap in memory which is not needed (left over initialization code, > error messages you never see, etc). > >> [1] >> http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that >> >> [2] >> http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_boring.htm >> >> [3] http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm >> > > Bill, You don't mention what types of tuning you've done to enforce a "balanced approach". Any suggestions are greatly appreciated! Kevin -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
