linux-kernel - Re: [PATCH -mm 1/3] exit: reparent: avoid find_new

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141121200138.GA21656@redhat.com>
Date:	Fri, 21 Nov 2014 21:01:38 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Aaron Tomlin <atomlin@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Sterling Alexander <stalexan@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm 1/3] exit: reparent: avoid find_new_reaper() if no
	children

On 11/20, Andrew Morton wrote:
>
> On Thu, 20 Nov 2014 19:34:23 +0100 Oleg Nesterov <oleg@...hat.com> wrote:
>
> > $ time ./test 16 16536 shows:
> >
> > 		real		user		sys
> > 	-	5m37.628s	0m4.437s	8m5.560s
> > 	+	0m50.032s	0m7.130s	1m4.927s
>
> Is that the best you can do?

Unfortunately these changes do not even try to solve the main problem,
tasklist_lock doesn't scale simply because it is global. These changes
make sense (I hope) anyway, even if/when we redesign the locking. But
so far I do not have a good plan.

> (I assume the increase in user time was a glitch?)

To be honest, I didn't even notice this change. I repeated the testing
before/after this patch and (to my surprize) the "user" numbers are more
or less stable, and /usr/bin/time reports the increase.

1. First of all: this is impossible ;)

   Note that this test-case uses SIGTRAP to trigger the coredumping.
   This means that exit_notify() can only be called when all threads
   are already in kernel mode, the coredumping thread sleeps until
   they all are parked in exit_mm(). Until then this patch has no
   effect.

2. With this patch applied, I added mdelay(2) into forget_original_parent(),
   right after find_child_reaper(). And yes, this changes the numbers too:

   		real		user		sys
   		10m1.225s	0m5.443s	17m25.797s

   note that "user time" goes down.

3. So I think that this just reminds that utime/stime accounting isn't
   precise. sum_exec_runtime is accurate and thus we can more or less
   trust utime + stime, but utime/stime is random. Plus scale_stime()
   doesn't look very accurate too.

4. In this particular case the accounting is even more impresize, this
   test-case spends a lot of time in kernel mode with irqs disabled and
   this "freezes" task->stime.

5. That said, I still can't really understand why "user" grows. If I
   understand the calculations in cputime_adjust() correctly (probably
   I don't), it should not.

In short, I am a bit confused but I still don't think that this increase
is real.

Oleg.

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