DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=sihoIA7dzuYuzLrYVtGaLlj4KZca65OU62PAWqOEyoUGw767W1iwLtFwLlpqtcwn;
  h=Received:Message-Id:From:To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Message-Id: <226B561B-ABBC-4CBC-BFFE-0BA32FC561EE@earthlink.net>
From: Mitchell Erblich <erblichs@earthlink.net>
To: linux-kernel@vger.kernel.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Simple Code change suggestion : pdflush() : clean pages in 1/2 time
Date: Wed, 8 Jul 2009 13:03:28 -0700
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1175
Lines: 31

Group,

	pdflush threads clean dirty pages.

	Under the past simple assumption that a greater number of
	  page daemon threads will have the TENDENCY to clean
	  the pages faster.

	  A simple change is to create 2x the number of threads
	  within the same timeframe as before.
	
	   Thus, in mm/pdflush.c _pdflush() thread creation is done
	    in 1/2 HZ. ( "/" or ">>" , compiler will optimize)
	    Above 1 sec omment should also be changed.

	   IMO, We could do in 1/4 or 1/8 HZ,  but load (backlog of dirty  
pages)
	   should then be tracked and watermarks set and determine whether
	  keep adding  additional threads allows us to clean the pages faster.
	  (Yes, did that / done that and the code is/was ... too complicated)

	  The 2nd part is to prevent thread creation / destruction thrashing,
	  keep around the extra threads to handle the bursts of frees so HZ
	  is still kept to limit exit rate.

	Mitchell Erblich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/