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]
Date:	Fri, 1 May 2015 19:12:24 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, williams@...hat.com,
	Andrew Lutomirski <luto@...nel.org>, fweisbec@...hat.com,
	Peter Zijlstra <peterz@...radead.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable
 & enable from context tracking on syscall entry


* Rik van Riel <riel@...hat.com> wrote:

> On 05/01/2015 12:45 PM, Ingo Molnar wrote:
> > 
> > * Rik van Riel <riel@...hat.com> wrote:
> > 
> >> On 05/01/2015 12:37 PM, Ingo Molnar wrote:
> >>
> >>> Also note that this bit in context_tracking_enter():
> >>>
> >>>                         if (state == CONTEXT_USER) {
> >>>                                 trace_user_enter(0);
> >>>                                 vtime_user_enter(current);
> >>>                         }
> >>>
> >>>
> >>> is related to precise time measurement of user/kernel execution 
> >>> times, it's not needed by the scheduler at all, it's just exported 
> >>> to tooling. It's not fundamental to the scheduler.
> >>
> >> Any objections to the idea from the other thread to simply keep the 
> >> time accumulating in buffers in local_clock() units, and only update 
> >> the task vtime once a second or so?
> > 
> > So I really think per syscall overhead is the wrong thing to do for 
> > anything that a common distro enables.
> > 
> > I see very little use for such precise, high-freq measurements on 
> > normal systems - and abnormal systems could enable it dynamically just 
> > like they can enable syscall auditing.
> > 
> > I.e. I don't mind the occasional crazy piece of code, as long as it 
> > does not hurt the innocent.
> 
> Then how should/could we keep a rough idea of user / system / guest 
> time when running without a periodic timer tick?

So I'd split the timer tick into two parts: just the constant-work 
sampling bit that doesn't do much, and the variable-work part which 
gets essentially shut off when the timeout is far into the future.

Then we could do IRQ driven sampling without introducing variable 
amount jitter into hard-RT execution time.

I.e. much of what we do today, except that we could skip variable work 
such as the scheduler tick or (unforced) RCU processing like the RCU 
softirq work.

Thanks,

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ