linux-kernel - Re: [RFC PATCH 0/4] Gang scheduling in CFS

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1325712710.3084.10.camel@laptop>
Date:	Wed, 04 Jan 2012 22:31:50 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Avi Kivity <avi@...hat.com>
Cc:	Rik van Riel <riel@...hat.com>,
	Nikunj A Dadhania <nikunj@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	vatsa@...ux.vnet.ibm.com, bharata@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH 0/4] Gang scheduling in CFS

On Wed, 2012-01-04 at 19:16 +0200, Avi Kivity wrote:
> 
> 
> I think we can solve it at the guest level.  The paravirt ticketlock
> stuff introduces wait/wake calls (actually wait is just a HLT
> instruction); we could spin for a while, then HLT until the other side
> wakes us.  We should do this for all sites that busy wait.
> 
This is all TLB invalidates, right?

So why wait for non-running vcpus at all? That is, why not paravirt the
TLB flush such that the invalidate marks the non-running VCPU's state so
that on resume it will first flush its TLBs. That way you don't have to
wake it up and wait for it to invalidate its TLBs.

Or am I like totally missing the point (I am after all reading the
thread backwards and I haven't yet fully paged the kernel stuff back
into my brain).

I guess tagging remote VCPU state like that might be somewhat tricky..
but it seems worth considering, the whole wake and wait for flush thing
seems daft.

--
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/