linux-kernel - Re: [PATCH 44/51] writeback: implement bdi_wait_for

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, 3 Jul 2015 13:02:10 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kara <jack@...e.cz>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org, hch@...radead.org,
	hannes@...xchg.org, linux-fsdevel@...r.kernel.org,
	vgoyal@...hat.com, lizefan@...wei.com, cgroups@...r.kernel.org,
	linux-mm@...ck.org, mhocko@...e.cz, clm@...com,
	fengguang.wu@...el.com, david@...morbit.com, gthelen@...gle.com,
	khlebnikov@...dex-team.ru
Subject: Re: [PATCH 44/51] writeback: implement bdi_wait_for_completion()

Hello,

On Fri, Jul 03, 2015 at 02:36:42PM +0200, Jan Kara wrote:
> Let me phrase my objection this differently: Instead of implementing custom
> synchronization mechanism, you could as well do:
> 
> int count_submitted;	/* Number of submitted works we want to wait for */
> struct completion done;
> ...
> submit works with 'done' as completion.
> ...
> while (count_submitted--)
> 	wait_for_completion(&done);
> 
> And we could also easily optimize that loop and put it in
> kernel/sched/completion.c. The less synchronization mechanisms we have the
> better I'd think...

And what I'm trying to say is that we most likely don't want to build
it around completions.  We really don't want to roll "event count" and
"wakeup count" into the same mechanism.  There's nothing completion
provides that such event counting mechanism needs or wants.  It isn't
that attractive from the completion side either.  The main reason we
have completions is for stupid simple synchronizations and we wanna
keep it simple.

I do agree that we might want a generic "event count" mechanism but at
the same time combining a counter and wait_event is usually pretty
trivial.  Maybe atomic_t + waitqueue is a useful enough abstraction
but then we would eventually end up having to deal with all the
different types of waits and timeouts.  We might end up with a lot of
thin wrappers which really don't do much of anything.

If you can think of a good way to abstract this, please go head.

Thanks.

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