linux-kernel - Re: vmstat: On demand vmstat workers V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 24 Apr 2014 09:29:57 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Max Krasnyansky <maxk@....qualcomm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Kevin Hilman <khilman@...aro.org>
Cc:	Christoph Lameter <cl@...ux.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tejun Heo <tj@...nel.org>, John Stultz <johnstul@...ibm.com>,
	Mike Frysinger <vapier@...too.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org
Subject: Re: vmstat: On demand vmstat workers V3

On 23 April 2014 22:20, Max Krasnyansky <maxk@....qualcomm.com> wrote:
> On 04/22/2014 03:32 AM, Viresh Kumar wrote:
>> This vmstat interrupt is disturbing my core isolation :), have you got
>> any far with this patchset?
>
> You don't mean an interrupt, right?

Sorry for not being clear enough. I meant the interruption caused due to these
works.

> The updates are done via the regular priority workqueue.
>
> I'm playing with isolation as well (has been more or less a background thing
> for the last 6+ years). Our threads that run on the isolated cores are SCHED_FIFO
> and therefor low prio workqueue stuff, like vmstat, doesn't get in the way.

Initially I thought that's not enough. As there were queued with a delayed work
and so a timer+work. Because there is a timer to fire, kernel wouldn't stop
the tick for long  with NO_HZ_FULL as get_next_timer_interrupt() wouldn't
return KTIME_MAX. And so we will stop the tick for some time but will still
queue a hrtimer after say 'n' seconds. But the clockevent device will have
a max value of counter it is running and it will disturb isolation
with a interrupt
after end of counter, for me it is 90 seconds.

BUT, it looks there is something else as well here. For the first time this
theory would probably work, but because we wouldn't allow the work
to run, the timer wouldn't get queued again. And so things will start working
soon after.

While writing this mail, I got another vision at this point. Because there will
be one task running and another queued for the work, tick wouldn't be
stopped (nr_running > 1) :( .. And so isolation wouldn't work again.

@Frederic/Kevin: Did we ever had a discussion about stopping tick even if
we have more than a task in queue but are SCHED_FIFO ?

> I do have a few patches for the workqueues to make things better for isolation.

Please share them, even if they aren't mainlinable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/