Hello, Neil.
(cc'ing Lai)
On Fri, Nov 20, 2020 at 10:07:56AM +1100, NeilBrown wrote:
> If the workqueue maintainers are unmovable in the position that a
> CM-workitem must not use excessive CPU ever, and so must not call
> cond_resched(), then I can take that back to the NFS maintainers and
Oh,
Hello,
On Fri, Nov 20, 2020 at 10:23:44AM +1100, NeilBrown wrote:
> On Mon, Nov 09 2020, t...@kernel.org wrote:
>
> >Given that nothing on
> > these types of workqueues can be latency sensitive
>
> This caught m
Hello,
On Mon, Nov 09, 2020 at 02:11:42PM +, Trond Myklebust wrote:
> That means changing all filesystem code to use cpu-intensive queues. As
> far as I can tell, they all use workqueues (most of them using the
> standard system queue) for fput(), dput() and/or iput() calls.
I suppose the ass
Hello,
On Mon, Nov 09, 2020 at 01:50:40PM +, Trond Myklebust wrote:
> > I'm thinking the real problem is that you're abusing workqueues. Just
> > don't stuff so much work into it that this becomes a problem. Or
> > rather,
> > if you do, don't lie to it about it.
>
> If we can't use workqueue
Hello,
On Fri, May 01, 2020 at 07:05:46PM +, Trond Myklebust wrote:
> Wen running an instance of knfsd from inside a container, you want to
> be able to have the knfsd kthreads be parented to the container init
> process so that they get killed off when the container is killed.
>
> Right now,
Hello,
On Tue, Jun 05, 2018 at 10:31:36AM -0500, Eric W. Biederman wrote:
> What I have above is not the clearest, and in fact the logic could be
> better.
>
> The fundamental challenge is because hash collisions are possible a file
> offset does not hold complete position information in a direct
Hello,
On Fri, Jun 01, 2018 at 09:25:32AM +, Hatayama, Daisuke wrote:
> kernfs_dir_pos() checks if a kernfs_node object given as one of its
> arguments is still active and if so returns it, or returns a
> kernfs_node object that is most equal (possibly smaller and larger) to
> the given object
Hello,
On Mon, May 28, 2018 at 12:54:03PM +, Hatayama, Daisuke wrote:
> diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
> index 89d1dc1..3aeeb7a 100644
> --- a/fs/kernfs/dir.c
> +++ b/fs/kernfs/dir.c
> @@ -1621,8 +1621,10 @@ static int kernfs_dir_fop_release(struct inode *inode,
> struct file
On Wed, Apr 11, 2018 at 08:00:29PM +, Bart Van Assche wrote:
> On Wed, 2018-04-11 at 12:57 -0700, t...@kernel.org wrote:
> > On Wed, Apr 11, 2018 at 01:55:25PM -0600, Bart Van Assche wrote:
> > > On 04/11/18 13:00, Alexandru Moise wrote:
> > > > But the root caus
On Wed, Apr 11, 2018 at 01:55:25PM -0600, Bart Van Assche wrote:
> On 04/11/18 13:00, Alexandru Moise wrote:
> >But the root cause of it is in blkcg_init_queue() when blkg_create() returns
> >an ERR ptr, because it tries to insert into a populated index into
> >blkcg->blkg_tree,
> >the entry that
Hello,
On Wed, Apr 11, 2018 at 05:26:12PM +, Bart Van Assche wrote:
> Please explain what you wrote further. It's not clear to me why you think
> that anything is broken nor what a "sever model" is.
So, sever (or revoke) model is where you actively disconnect an object
and ensuring that there
Hello,
On Wed, Apr 11, 2018 at 05:06:41PM +, Bart Van Assche wrote:
> A simple and effective solution is to dissociate a request queue from the
> block cgroup controller before blk_cleanup_queue() returns. This is why commit
> a063057d7c73 ("block: Fix a race between request queue removal and
Hello,
On Wed, Apr 11, 2018 at 04:42:55PM +, Bart Van Assche wrote:
> On Wed, 2018-04-11 at 07:56 -0700, Tejun Heo wrote:
> > And looking at the change, it looks like the right thing we should
> > have done is caching @lock on the print_blkg side and when switching
> > locks make sure both loc
Hello,
On Mon, Apr 02, 2018 at 10:09:18PM +, Bart Van Assche wrote:
> Please elaborate what your long-term goal is for the blk-mq timeout handler.
Hmm... I don't really have any plans beyond what's been posted.
> The legacy block layer suspends request state changes while a timeout is
> bein
Hello,
On Mon, Apr 02, 2018 at 09:56:41PM +, Bart Van Assche wrote:
> This patch increases the time during which .aborted_gstate == .gstate if the
> timeout is reset. Does that increase the chance that a completion will be
> missed
> if the request timeout is reset?
It sure does, but we're c
Hello,
On Mon, Apr 02, 2018 at 09:31:34PM +, Bart Van Assche wrote:
> > > > +* As nothing prevents from completion happening while
> > > > +* ->aborted_gstate is set, this may lead to ignored completions
> > > > +* and further spurious timeouts.
> > > > +*/
> >
Hello, Bart.
On Tue, Mar 06, 2018 at 05:52:50PM +, Bart Van Assche wrote:
> I think the rcu_read_lock() and rcu_read_unlock() are really necessary in this
> code. In the LWN article "The RCU-barrier menagerie" it is explained that RCU
> can be used to enforce write ordering globally if the cod
Hello, Bart.
On Tue, Jan 09, 2018 at 04:12:40PM +, Bart Van Assche wrote:
> I'm concerned about the additional CPU cycles needed for the new
> blk_mq_map_queue()
> call, although I know this call is cheap. Would the timeout code really get
> that
So, if that is really a concern, let's cache
On Mon, Jan 08, 2018 at 10:10:01PM +, Bart Van Assche wrote:
> Other req->deadline writes are protected by preempt_disable(),
> write_seqcount_begin(&rq->gstate_seq), write_seqcount_end(&rq->gstate_seq)
> and preempt_enable(). I think it's fine that the above req->deadline store
> does not have
On Mon, Jan 08, 2018 at 11:29:11PM +, Bart Van Assche wrote:
> Does "gstate" perhaps stand for "generation number and state"? If so, please
> mention this in one of the above comments.
Yeah, will do.
Thanks.
--
tejun
On Mon, Jan 08, 2018 at 09:06:55PM +, Bart Van Assche wrote:
> On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote:
> > +static void blk_mq_rq_update_aborted_gstate(struct request *rq, u64 gstate)
> > +{
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > + u64_stats_update_b
On Wed, Dec 20, 2017 at 11:41:02PM +, Bart Van Assche wrote:
> On Tue, 2017-12-12 at 11:01 -0800, Tejun Heo wrote:
> > Currently, blk-mq timeout path synchronizes against the usual
> > issue/completion path using a complex scheme involving atomic
> > bitflags, REQ_ATOM_*, memory barriers and su
Hello, Peter.
On Thu, Dec 14, 2017 at 09:20:42PM +0100, Peter Zijlstra wrote:
> But now that I look at this again, TJ, why can't the below happen?
>
> write_seqlock_begin();
> blk_mq_rq_update_state(rq, IN_FLIGHT);
> blk_add_timer(rq);
>
> read_seqcount_begi
Hello, Bart.
On Thu, Dec 14, 2017 at 09:13:32PM +, Bart Van Assche wrote:
...
> however is called before a every use of a request. Sorry but I'm not
> enthusiast about the code in blk_rq_init() that reinitializes state
> information that should survive request reuse.
If it wasn't clear, me ne
Hello,
On Thu, Dec 14, 2017 at 06:56:55PM +, Bart Van Assche wrote:
> On Tue, 2017-12-12 at 11:01 -0800, Tejun Heo wrote:
> > void blk_abort_request(struct request *req)
> > {
> > - if (blk_mark_rq_complete(req))
> > - return;
> >
> > if (req->q->mq_ops) {
> > - b
Hello,
On Thu, Dec 14, 2017 at 06:51:11PM +, Bart Van Assche wrote:
> On Tue, 2017-12-12 at 11:01 -0800, Tejun Heo wrote:
> > rules. Unfortunatley, it contains quite a few holes.
> ^
> Unfortunately?
>
> > While this change makes REQ_ATOM_COMPLETE synchornizat
On Thu, Dec 14, 2017 at 05:01:06PM +, Bart Van Assche wrote:
> On Tue, 2017-12-12 at 11:01 -0800, Tejun Heo wrote:
> > + } else {
> > + srcu_idx = srcu_read_lock(hctx->queue_rq_srcu);
> > + if (!blk_mark_rq_complete(rq))
> > + __blk_mq_complete_request(rq
On Tue, Dec 12, 2017 at 10:20:39PM +, Bart Van Assche wrote:
> The above code should show all requests owned by the block driver. Patch
> "blk-mq-debugfs: Also show requests that have not yet been started" (not yet
> in Jens' tree) changes the REQ_ATOM_STARTED test into
> list_empty(&rq->queue
Hello, Bart.
On Tue, Dec 12, 2017 at 09:37:11PM +, Bart Van Assche wrote:
> Have you considered the following instead of introducing MQ_RQ_IDLE and
> MQ_RQ_IN_FLIGHT? I think this could help to limit the number of new atomic
> operations introduced in the hot path by this patch series.
But no
Hello,
On Tue, Oct 10, 2017 at 04:48:57PM +, Trond Myklebust wrote:
> Thanks for the explanation. What I'm not really understanding here
> though, is how the work item could be queued at all. We have a
> wait_on_bit_lock() in xprt_destroy() that should mean the xprt-
> >task_cleanup work item
Hello, Trond.
On Mon, Oct 09, 2017 at 06:32:13PM +, Trond Myklebust wrote:
> On Mon, 2017-10-09 at 19:17 +0100, Lorenzo Pieralisi wrote:
> > I have run into the lockdep warning below while running v4.14-rc3/rc4
> > on an ARM64 defconfig Juno dev board - reporting it to check whether
> > it is
>From d786b91f422c6ad4c0d9bb9c1bef2dd5008e3d9d Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Mon, 23 Jan 2017 14:28:51 -0500
@t1 and @t2i are calculated along with @t2 but never used. Drop them.
Signed-off-by: Tejun Heo
Reported-by: David Binderman
---
Applied to libata/for-4.11. Thanks.
Hello,
On Mon, Nov 28, 2016 at 11:59:15AM +, Julien Grall wrote:
> > commit 3ca45a46f8af8c4a92dd8a08eac57787242d5021
> > percpu: ensure the requested alignment is power of two
>
> It would have been useful to specify the tree used. In this case,
> this commit comes from linux-next.
I'm surpr
Hello,
(cc'ing Dan, hi!)
On Thu, Sep 29, 2016 at 08:25:58AM -0300, Henrique de Moraes Holschuh wrote:
> Actually, according to Shah's post from the 26th to this thread,
> everything works just fine even with the IOMMU enabled, as long as the
> system is configured to NOT auto-shutdown unused SATA
Hello,
On Wed, Sep 28, 2016 at 05:45:08AM +, Shah, Nehal-bakulchandra wrote:
> Can someone please help me to debug this issue?
The only thing I can do from libata side is disbling msi on the
affected platform, but the problem doesn't seem confined to ahci, so
probably the right thing to do fo
On Wed, Jul 20, 2016 at 12:13:46PM +, Pang Raymond wrote:
>
> Due to PCI subsystem behaviour, unloading AHCI driver will disable
> MSI and enable INTx. When HBA supports MSIx or Multiple MSI, Driver's
> irq handler doesn't clear GHC.IS register. It works well when reading or
> writing data an
Hello, Pang.
On Fri, Jul 15, 2016 at 12:39:59PM +, Pang Raymond wrote:
> Hi Tejun,
>
>
> Yes! It only happens when the device is shutdown.
>
> I think you're right. It's more wiser to add clearing operation to driver
>
> clean up path.
>
> So we can add it to ahci_port_stop()
>
>
> liba
Hello,
On Mon, Jul 11, 2016 at 05:16:00AM +, Pang Raymond wrote:
> static irqreturn_t ahci_multi_irqs_intr_hard(int irq,
> void *dev_instance)
> {
> // omitting unconcerned codes here
> // ...
>status = readl(port_mmio + PORT_IRQ_STAT);
>writel(status, po
Hello,
(Can you please flow the text a bit below 80 column when you reply?)
On Wed, Jul 06, 2016 at 02:51:47AM +, Pang Raymond wrote:
> Why does the phenomenon appear?
> Two factors cause this problem.
> 1. In MSIx's irq handler
> (ahci_multi_irqs_intr_har
Hello,
On Thu, Mar 17, 2016 at 12:43:35PM +, Grumbach, Emmanuel wrote:
> >
> > Use alloc_workqueue() to allocate the workqueue instead of
> > create_singlethread_workqueue() since the latter is deprecated and is
> > scheduled
> > for removal.
>
> I can't see any indication of that in the cod
Hello, Alex.
On Tue, Dec 22, 2015 at 07:06:41PM +, Alex Ng (LIS) wrote:
> > Can you please let me know the steps to reproduce the bug?
>
> I tried this on a Hyper-V VM hosted in Windows Server 2012R2 and ran
> the attached script. The script clones the linux-next tree in a
> random directory
Hello, Alex.
On Fri, Dec 18, 2015 at 08:08:03PM +, Alex Ng (LIS) wrote:
> Hi,
>
> I was running a "git clone" of the linux-next source tree and hit the
> following BUG_ON condition. My box is running kernel
> 4.4.0-rc5-next-20151217-52.27. Any ideas on how to pin down the cause?
>
> The tr
Hello,
On Wed, Jun 17, 2015 at 06:04:06PM +0800, songxium...@inspur.com wrote:
> Subject: [PATCH] hotplug: fix oops when adding cpu
> From: SongXiumiao
>
> If memory is not in node0 and a cpu is logically hotadded, the kernel oopses.
>
> By analysing the bug function call trace,we find that cr
Hello, Nick.
On Fri, Dec 26, 2014 at 04:06:11PM -0500, nick wrote:
> I am assuming after reading this function's code, that this function is
> completed and no longer
> needs a fix me comment above it to be completed.
I do appreciate that you're studying the FIXME comments but at this
point I'm
Hello,
On Thu, Nov 07, 2013 at 12:36:56AM +, Liu, Chuansheng wrote:
> Yes, I knew I can put the code always like below:
> A = devm_kzalloc();
> C = devm_kzalloc();
> ...
> B= devm_request_threaded_irq(isr_handler);
>
> But, the above is just one simple coding prototype, if there are many call
Hello, Liu.
On Thu, Nov 07, 2013 at 12:27:56AM +, Liu, Chuansheng wrote:
> The driver code is as below:
> _INIT() {
>
> A = devm_kzalloc();
> B= devm_request_threaded_irq(isr_handler);
> C = devm_kzalloc();
> }
>
> When driver _EXIT, the devres_release_all () will be called.
> The C will be
>From 867974fc09f93bdd7f98d46ac3733934486bbf4a Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 26 Jul 2013 08:57:56 -0400
ahci_imx makes use of regmap but the dependency wasn't specified in
Kconfig leading build failures if CONFIG_AHCI_IMX is enabled but
CONFIG_MFD_SYSCON is not. Add the Kco
On Fri, Jul 26, 2013 at 01:25:21PM +0800, Shawn Guo wrote:
> On Fri, Jul 26, 2013 at 04:58:14AM +, Zhu Richard-R65037 wrote:
> > Hi Shawn:
> > yes, it is.
> >
> > BTW, Should I re-send the AHCI_IMX patch-set or send out one stand-alone
> > patch to fix this issue?
> >
>
> I think an increme
48 matches
Mail list logo
