Date: Mon, 11 May 2015 17:11:09 +1000
From: NeilBrown <neilb@suse.de>
To: Julian Anastasov <ja@ssi.bg>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched: Introduce TASK_NOLOAD and TASK_IDLE
Message-ID: <20150511171109.46e07c67@notabene.brown>
In-Reply-To: <alpine.LFD.2.11.1505090910060.1671@ja.home.ssi.bg>
References: <20150508124748.GH27504@twins.programming.kicks-ass.net>
	<alpine.LFD.2.11.1505090910060.1671@ja.home.ssi.bg>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 boundary="Sig_/AWAq/jOi.iOCZvmCioMu2E/"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3294
Lines: 93

--Sig_/AWAq/jOi.iOCZvmCioMu2E/
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 9 May 2015 11:49:01 +0300 (EEST) Julian Anastasov <ja@ssi.bg> wrote:

>=20
> 	Hello,
>=20
> On Fri, 8 May 2015, Peter Zijlstra wrote:
>=20
> > Subject: sched: Introduce TASK_NOLOAD and TASK_IDLE
> > From: Peter Zijlstra <peterz@infradead.org>
> > Date: Fri May 8 14:23:45 CEST 2015
> >=20
> > Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for
> > 'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having
> > all idle kthreads contribute to the loadavg is somewhat silly.
> >=20
> > Now mostly this works OK, because kthreads have all their signals
> > masked. However there's a few sites where this is causing problems and
> > TASK_UNINTERRUPTIBLE should be used, except for that loadavg issue.
> >=20
> > This patch adds TASK_NOLOAD which, when combined with
> > TASK_UNINTERRUPTIBLE avoids the loadavg accounting.
> >=20
> > As most of imagined usage sites are loops where a thread wants to
> > idle, waiting for work, a helper TASK_IDLE is introduced.
>=20
> 	After checking our code in net/netfilter/ipvs/ip_vs_sync.c,
> sync_thread_master(), we may also need some wrappers:
>=20
> - schedule_timeout_idle (instead of schedule_timeout call):
> 	__set_current_state(TASK_IDLE);
> 	return schedule_timeout(timeout);
>=20
> 	- we here are really idle, so "N" looks ok

yes, I would want
 wait_event_idle_timeout() and wait_event_idle()

but I'll be happy to take whatever I can get :-)

Thanks,
NeilBrown


>=20
> - pair of __wait_event_idle(wq, condition) and
> 	wait_event_idle(wq, condition) macros
>=20
> 	- we here are write-blocked for socket, not sure
> 	if this blocked vs idle difference is useful to
> 	represent, in new bit for this blocked state "B"=3D2048,
> 	with 2 TASK_NOLOAD variants: N(idle) and B(blocked,
> 	2|1024|2048, eg. for read-blocked or write-blocked).
> 	It will need additional argument 'state'/'blocked' for=20
> 	*wait_event_idle().
>=20
> Regards
>=20
> --
> Julian Anastasov <ja@ssi.bg>


--Sig_/AWAq/jOi.iOCZvmCioMu2E/
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBVVBWDTnsnt1WYoG5AQIdMA/+ILC6xBEjtLduJtX0iAYQ90XL66QiQ9oC
aeoJx0vyiT23YiaugvGisK0j7kpe22U09kHJ1ee7Qu7zUYYFnPPGBG5WmnCpQNgo
16PmmXTzz6Y5rKaJXL1e+oH16r19HRD2M25X7LfeZE42ZJwm58KPrsBF9pCAxUFf
zJMnem7ip9TXBO/fUrHNIAeq648lco8abJAP3kks/UqkBn2Ww8vNpY2RvvD9/yt2
h4hVKxTxRjO0Jzb6s/u6JMvze/3EP9oMsILWARaXt6QPu46HgEsTvluaBKhxsfaD
k+m90v8fRbu9x+Pfz4Hh/rzjiEtchTCS5QBTidZl6ogjumhtl6snQ+0ipLLQstpN
gqfRaoARVdvhsEpXzZydnuwgidu9Q1ltRyqfZaezSCri9wn9kaSWMHWc3YB8MLsq
NZ71oZsFRcBqr3nTVSilxRe5Ksick+WIFCDQAzFf9je+QOpxqE149K4u/FxgObL9
rYXS12b1EahX2RgR3CR2mpHw8KRm+jFP3sD+l5kKA9yC+aSk3Mk6KA2Hr5CIoOQA
PaCTy6mA+Ue+EZWhh62YUchh2TbdGmSM8hnxK5SnK7U0FFIYj5GtKYX//z5oYRCa
maLpSsCBhzx0oNESxQyh7nRlO9dd1QkJES9spR7bRf/HkEuRbQVE4Z+zHmhivTvA
Ij441hO4MZQ=
=TEId
-----END PGP SIGNATURE-----

--Sig_/AWAq/jOi.iOCZvmCioMu2E/--
--
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/