linux-kernel - Re: [PATCH UPDATED] workqueue: add documentation

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:	Thu, 9 Sep 2010 20:50:56 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	lkml <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Dave Chinner <david@...morbit.com>
Subject: Re: [PATCH UPDATED] workqueue: add documentation

On Thu, 09 Sep 2010 12:22:22 +0200
Tejun Heo <tj@...nel.org> wrote:

> The backend mechanism is called Global CPU Workqueue (gcwq).  There is

I tried to avoid that name. It somehow is confusing to me . Global/Local
in context of CPU is somehow associated with CPU locality in my mind.
Also the name doesn't fit for the unbound gcwq. 
I know what you mean by it, but I don't think it's a self explanatory
name. That was why I just said "they are called gcwq". But I'm ok with
it either way. After all, that _is_ how they are called. :) 


> > 
> > I think it is worth mentioning all functions that are considered to be
> > part of the API here. 
> 
> Yeah, that would be nice but a slightly larger task that I would like
> to postpone at this point.  :-)

Ah well, I may just give it a go then... 

> 
> > "Unless work items are expected to consume a huge amount of CPU
> > cycles, using a bound wq is usually beneficial due to the increased
> > level of locality in wq operations and work item exection. "
> 
> So updated.
> 
> > Btw, it is not clear to me, what you mean with "wq operations". 
> 
> Queueing, dispatching and other book keeping operations.

Yes. That makes sense. 

> 
> > Do the enqueuing API functions automatically determine the cpu they are
> > executed on and queue the workitem to the corresponding gcwq? Or do you
> > need to explicitly queue to a specific CPU?
> > 
> > Either you mean the operations that lead to the enqueueing of the
> > work-item, or you mean the operations done by the thread-pool?
> > 
> > ... after thinking a bit, the wq implementation should obviously do the
> > automatic enqueuing on the nearest gcwq thingy... But that should
> > probably be mentioned in the API description. 
> > Although I have to admit I only skimmed over the flag description
> > above it seems you only mention the UNBOUND case and not the default
> > one?
> 
> Yeah, queue_work() queues works on the gcwq of the local CPU.  It can
> be overridden by queue_work_on().  The unbound is special case where
> the workqueue always sends works to the unbound gcwq which is served
> by unbound workers.  Did the update in the design section explain
> enough or do you think there needs to be more explanation?

I'm looking forward to reading the new version en
bloc, but if I can trust my gut feeling, I'm ok with it now. :)

Let's see if someone else with more kernel-experience has something to
add, but here you've got my

Reviewed-By: Florian Mickler <florian@...kler.org>

in any case.

Cheers,
Flo
--
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/