linux-kernel - Re: [accounting regression since rc1] scheduler updates

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: <20070821113037.GA2390@elte.hu>
Date:	Tue, 21 Aug 2007 13:30:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christian Borntraeger <borntraeger@...ibm.com>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Jan Glauber <jang@...ux.vnet.ibm.com>,
	heiko.carstens@...ibm.com, Paul Mackerras <paulus@...ba.org>
Subject: Re: [accounting regression since rc1]  scheduler updates

* Christian Borntraeger <borntraeger@...ibm.com> wrote:

> Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> > you mean to revert b27f03d4bd? I'd really like to see this fixed for 
> > real for s390 + CONFIG_VIRT_CPU_ACCOUNTING=y. (which seems to be the 
> > only case affected)
> 
> Not a complete revert, but an ifdef-workaround. I wrote this patch last week 
> and you were on cc:
> http://marc.info/?l=linux-mm-commits&m=118737949222362&w=2
> 
> This patch should fix s390 and let everybody else use your new code. 
> If you are conviced that we get a better solution before 2.6.23 hits 
> the street, thats fine with me.

what do you think about the rq_clock() #ifdef i did in the previous mail 
plus you making sched_clock() virtual? That way you can keep 
scheduler_tick() driven by real-time, although that generally will cause 
artifacts with SMP load-balancing too. (that was true in the past too)

but i dont mind your patch either - it's really the architecture's 
choice how visible it wants to make external load to the task stats of 
its virtual machines. I think it is more logical to say that 100% CPU 
time displayed in 'top' means that the task got all the CPU time it 
asked for from the virtual machine. (and if you are curious about how 
much time was stolen from the virtual box altogether you look at the 
stolen-time stats in isolation.)

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