linux-kernel - Re: [PATCH] kthread: Don't looking for a task in create

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: <200901202019.56972.vgusev@openvz.org>
Date:	Tue, 20 Jan 2009 20:19:56 +0300
From:	Vitaliy Gusev <vgusev@...nvz.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
	Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [PATCH] kthread: Don't looking for a task in create_kthread() #2

On 20 January 2009 18:00:19 Oleg Nesterov wrote:
> On 01/20, Vitaliy Gusev wrote:
> >
> > On 20 January 2009 15:06:42 Oleg Nesterov wrote:
> > >
> > > BTW. Perhaps it also makes sense to move sched_setscheduler/etc code
> > > from create_kthread() to kthread_create(), what do you think?
> >
> > I don't thinks so. create_kthread() is executed in kthreadd process and
> > sched_setscheduler/etc preparation things are reflected to kthreadd's CPU usage.
> > In other words it is a kthreadd matter, start and setup a thread.
> 
> can't understand...
> 
> Perhaps I missed something, but from the correctness pov it doesn't
> matter who does sched_setscheduler/etc (except _nocheck() would be
> better). However it does matter from the scalability pov, we should
> move as much as possible from create_kthread() because we have a
> single process with executes the "create" requests.

Ok, I understand you. You want to decrease kthreadd latency. In this case
your suggestion is right.

> 
> OK, please forget. This reminds me kthread.c needs a major rework
> anyway, hopefully I'll try to do this soon.

I also have intent to make kthread_run/kthread_create more easy used for
threads that exit himself on error.
For example, we create some thread THR, which does something but exits on error.
So in normal case we need to call kthread_stop() to stop thread THR, but on
error we don't. This is a problem, because we can't simple (without race) 
determine that THR was exited.
Simple workaround - do a sleeping loop in thread THR and don't exit until kthread_should_stop.
But it isn't a good for code reading/writing.

So my suggestion is: Move workaround sleeping logic from THR to low level
functions:
   wait for a kthread_should_stop in kthread() if THR was exited.
Of course don't wait if nobody cares about thread THR (nobody calls kthread_stop()
for this thread).

That do you think about it?

> 
> Oleg.
> 

-- 
Thank,
Vitaliy Gusev
--
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/