From: Huang Ying <ying.huang@intel.com>
To: Tejun Heo <tj@kernel.org>
Cc: Tony Luck <tony.luck@intel.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Borislav Petkov <bp@amd64.org>,
Chen Gong <gong.chen@linux.intel.com>,
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Subject: Re: x86, mce, Use user return notifier in mce
Date: Sat, 21 Jan 2012 10:44:03 +0800 [thread overview]
Message-ID: <1327113843.7922.27.camel@yhuang-dev> (raw)
In-Reply-To: <20120120173427.GC3336@dhcp-172-17-108-109.mtv.corp.google.com>
On Fri, 2012-01-20 at 09:34 -0800, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 16, 2012 at 09:21:15AM +0800, Huang Ying wrote:
> > "high priority work queue" sounds like a good idea.
> >
> > Hi, Tejun,
> >
> > Do you think the concept of "high priority work queue" is possible?
> > This is the requirement from our RAS guys. To make some hardware
> > recovery function to be executed ASAP in process context.
>
> Take a look at Documentation/workqueue.txt. It already has
> WQ_HIGHPRI.
Thanks for reminding!
It appears that WQ_HIGHPRI only provides priority between work queue,
not between the work queue backing kthread and other tasks. Is there
any mechanism for that?
If my understanding was correct, WQ_MEM_RECLAIM has some side-effect for
that. Because hardware errors occurs seldom, the reserved kthread for
WQ_MEME_RECLAIM just sleeps most of the time. When first hardware error
occurs and the work item is queued, the reserved kthread is waked up.
Because the reserved kthread sleeps for long time, it is highly possible
for it to be scheduled at the next schedule point.
Because hardware error usually has no locality, WQ_UNBOUND can be used
for it so that the work item can be put on relative low-load CPU. From
the document, it is said WQ_UNBOUND work items will be executed ASAP
too. Compared with WQ_HIGHPRI, how about the priority of WQ_UNBOUND?
Best Regards,
Huang Ying
next prev parent reply other threads:[~2012-01-21 2:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-13 0:36 Huang Ying
2012-01-13 0:36 ` [RFC 1/2] urn, make user return notifier lockless Huang Ying
2012-01-13 0:36 ` [RFC 2/2] x86, mce, Use user return notifier in mce Huang Ying
2012-01-13 1:46 ` Tony Luck
2012-01-13 6:32 ` Huang Ying
2012-01-13 7:41 ` Tony Luck
2012-01-16 1:21 ` Huang Ying
2012-01-20 17:34 ` Tejun Heo
2012-01-21 2:44 ` Huang Ying [this message]
2012-01-21 5:56 ` Tejun Heo
2012-01-21 6:19 ` Huang Ying
2012-01-23 23:00 ` Luck, Tony
2012-01-24 14:39 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1327113843.7922.27.camel@yhuang-dev \
--to=ying.huang@intel.com \
--cc=bp@amd64.org \
--cc=gong.chen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tj@kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome