Re: [PATCH] power: reset: hisi-reboot: use the correct HiSilicon copyright

Hi, On Tue, Mar 30, 2021 at 08:40:48AM +, Haojian Zhuang wrote: > On 3/30/21 2:38 PM, Hao Fang wrote: > > s/Hisilicon/HiSilicon/g. > > It should use capital S, according to > > https://www.hisilicon.com/en/terms-of-use. > > > > Signed-off-by: Hao Fang > > --- > >

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

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,

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

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

Re: [PATCH net-next 2/2] net: nfc: s3fwrn5: Support a UART interface

On Tue, Nov 24, 2020 at 09:05:52PM +0900, Bongsu Jeon wrote: > On Mon, Nov 23, 2020 at 5:55 PM k...@kernel.org wrote: > > > +static enum s3fwrn5_mode s3fwrn82_uart_get_mode(void *phy_id) > > > +{ > > > + struct s3fwrn82_uart_phy *phy = phy_id; >

Re: [PATCH net-next 1/2] dt-bindings: net: nfc: s3fwrn5: Support a UART interface

On Tue, Nov 24, 2020 at 08:39:40PM +0900, Bongsu Jeon wrote: > On Mon, Nov 23, 2020 at 5:02 PM k...@kernel.org wrote: > > > > On Mon, Nov 23, 2020 at 04:55:26PM +0900, Bongsu Jeon wrote: > > examples: > > >- | > > > #include > > > @@ -

Re: [PATCH net-next 2/2] net: nfc: s3fwrn5: Support a UART interface

On Mon, Nov 23, 2020 at 04:56:58PM +0900, Bongsu Jeon wrote: > Since S3FWRN82 NFC Chip, The UART interface can be used. > S3FWRN82 uses NCI protocol and supports I2C and UART interface. > > Signed-off-by: Bongsu Jeon Please start sending emails properly, e.g. with git send-email, so all your

Re: [PATCH net-next 1/2] dt-bindings: net: nfc: s3fwrn5: Support a UART interface

On Mon, Nov 23, 2020 at 04:55:26PM +0900, Bongsu Jeon wrote: > Since S3FWRN82 NFC Chip, The UART interface can be used. > S3FWRN82 supports I2C and UART interface. > > Signed-off-by: Bongsu Jeon > --- > .../bindings/net/nfc/samsung,s3fwrn5.yaml | 28 +-- > 1 file changed, 26

Re: [PATCH net-next v2 1/3] nfc: s3fwrn5: Remove the max_payload

On Tue, Nov 17, 2020 at 10:16:11AM +0900, Bongsu Jeon wrote: > max_payload is unused. Why did you resend the patch ignoring my review? I already provided you with a tag, so you should include it. https://www.kernel.org/doc/html/latest/process/submitting-patches.html Reviewed-by: Krzysztof

Re: [PATCH net-next v2 2/3] nfc: s3fwrn5: Fix the misspelling in a comment

On Tue, Nov 17, 2020 at 10:17:42AM +0900, Bongsu Jeon wrote: > stucture should be replaced by structure. > > Signed-off-by: Bongsu Jeon I already reviewed it. Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof

Re: [PATCH net-next v2 3/3] nfc: s3fwrn5: Change the error code

On Tue, Nov 17, 2020 at 10:18:50AM +0900, Bongsu Jeon wrote: > ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP. > > Signed-off-by: Bongsu Jeon > --- > drivers/nfc/s3fwrn5/s3fwrn5.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) I already reviewed it. Reviewed-by:

Re: [PATCH net-next 2/3] nfc: s3fwrn5: Fix the misspelling in a comment

On Mon, Nov 16, 2020 at 10:17:55AM +0900, Bongsu Jeon wrote: > stucture should be replaced by structure. > > Signed-off-by: Bongsu Jeon > --- > drivers/nfc/s3fwrn5/firmware.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof

Re: [PATCH net-next 3/3] nfc: s3fwrn5: Change the error code

On Mon, Nov 16, 2020 at 10:19:50AM +0900, Bongsu Jeon wrote: > ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP. > > Signed-off-by: Bongsu Jeon > --- > drivers/nfc/s3fwrn5/s3fwrn5.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best

Re: [PATCH net-next 1/3] nfc: s3fwrn5: Remove the max_payload

On Mon, Nov 16, 2020 at 10:12:05AM +0900, Bongsu Jeon wrote: > max_payload is unused. > > Signed-off-by: Bongsu Jeon Please version your patches (this should be a v2) and describe changes between versions in changelog, either in cover letter or after --- separator. Reviewed-by: Krzysztof

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

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

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

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

Re: [PATCH] dt-bindings: mfd: Correct interrupt flags in examples

On Wed, Sep 09, 2020 at 08:57:36AM +, Vaittinen, Matti wrote: > Hello Krzysztof, > > On Wed, 2020-09-09 at 10:17 +0200, k...@kernel.org wrote: > > On Wed, Sep 09, 2020 at 06:30:44AM +, Vaittinen, Matti wrote: > > > On Tue, 2020-09-08 at 16:59 +0200, K

Re: [PATCH] dt-bindings: mfd: Correct interrupt flags in examples

On Wed, Sep 09, 2020 at 06:30:44AM +, Vaittinen, Matti wrote: > > On Tue, 2020-09-08 at 16:59 +0200, Krzysztof Kozlowski wrote: > > GPIO_ACTIVE_x flags are not correct in the context of interrupt > > flags. > > These are simple defines so they could be used in DTS but they will > > not > >

Re: [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema

On Tue, Aug 25, 2020 at 08:22:18AM +, Vaittinen, Matti wrote: > Hello Krzysztof, > > On Tue, 2020-08-25 at 09:50 +0200, k...@kernel.org wrote: > > On Tue, Aug 25, 2020 at 09:45:00AM +0200, k...@kernel.org wrote: > > > On Tue, Aug 25, 2020 at 09:25:37AM +020

Re: [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema

On Tue, Aug 25, 2020 at 09:45:00AM +0200, k...@kernel.org wrote: > On Tue, Aug 25, 2020 at 09:25:37AM +0200, k...@kernel.org wrote: > > On Tue, Aug 25, 2020 at 06:51:33AM +, Vaittinen, Matti wrote: > > > Hello Krzysztof, > > > > > > Just some question

Re: [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema

On Tue, Aug 25, 2020 at 09:25:37AM +0200, k...@kernel.org wrote: > On Tue, Aug 25, 2020 at 06:51:33AM +, Vaittinen, Matti wrote: > > Hello Krzysztof, > > > > Just some questions - please ignore if I misunderstood the impact of > > the change. > > >

Re: [PATCH 03/16] arm64: dts: imx8mm-beacon-som.dtsi: Align regulator names with schema

On Tue, Aug 25, 2020 at 06:51:33AM +, Vaittinen, Matti wrote: > Hello Krzysztof, > > Just some questions - please ignore if I misunderstood the impact of > the change. > > On Mon, 2020-08-24 at 21:06 +0200, Krzysztof Kozlowski wrote: > > Device tree schema expects regulator names to be

Re: [PATCH 01/16] dt-bindings: mfd: rohm,bd71847-pmic: Correct clock properties requirements

On Tue, Aug 25, 2020 at 06:23:36AM +, Vaittinen, Matti wrote: > > Hello Krzysztof, > > On Mon, 2020-08-24 at 21:06 +0200, Krzysztof Kozlowski wrote: > > The input clock and number of clock provider cells are not required > > for > > the PMIC to operate. They are needed only for the optional

Re: [PATCH -next] power: supply: Make bd9995x_chip_reset static

Hi, On Mon, May 11, 2020 at 11:22:26AM +, Vaittinen, Matti wrote: > On Mon, 2020-05-11 at 19:12 +0800, Samuel Zou wrote: > > Fix the following sparse warning: > > > > drivers/power/supply/bd99954-charger.c:1028:6: warning: symbol > > 'bd9995x_chip_reset' was not declared. > > > > The

Re: [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings

> > > +st,smbus-alert: > > > + description: Enable the SMBus Alert feature > > > + $ref: /schemas/types.yaml#/definitions/flag > > > + > > > > We already have smbus_alert interrupt. Can't you just check for this in > > the slave nodes and enable if found? > > My

Re: [PATCH v12 09/11] power: supply: Support ROHM bd99954 charger

Hi, On Fri, May 08, 2020 at 03:59:18PM +, Vaittinen, Matti wrote: > On Fri, 2020-05-08 at 18:50 +0300, Matti Vaittinen wrote: > > The ROHM BD99954 is a Battery Management LSI for 1-4 cell Lithium-Ion > > secondary battery intended to be used in space-constraint equipment > > such > > as Low

Re: [PATCH 0/4] allow multiple kthreadd's

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

Re: [PATCH 05/10] ARM: dts: imx6ul-kontron-n6x1x: Add 'chosen' node with 'stdout-path'

On Wed, Oct 16, 2019 at 03:07:28PM +, Schrempf Frieder wrote: > From: Frieder Schrempf > > The Kontron N6x1x SoMs all use uart4 as a debug serial interface. > Therefore we set in the 'chosen' node. > > Signed-off-by: Frieder Schrempf > --- >

Re: [PATCH 09/10] dt-bindings: arm: fsl: Add more Kontron i.MX6UL/ULL compatibles

On Wed, Oct 16, 2019 at 03:07:36PM +, Schrempf Frieder wrote: > From: Frieder Schrempf > > Add the compatibles for Kontron i.MX6UL N6311 SoM and boards and > the compatibles for Kontron i.MX6ULL N6411 SoM and boards. > > Signed-off-by: Frieder Schrempf > --- >

Re: [PATCH 04/10] ARM: dts: Add support for two more Kontron evalkit boards 'N6311 S' and 'N6411 S'

On Wed, Oct 16, 2019 at 03:07:28PM +, Schrempf Frieder wrote: > From: Frieder Schrempf > > The 'N6311 S' and the 'N6411 S' are similar to the Kontron 'N6310 S' > evaluation kit boards. Instead of the N6310 SoM, they feature a N6311 > or N6411 SoM. > > Signed-off-by: Frieder Schrempf > ---

Re: [PATCH 03/10] ARM: dts: imx6ul-kontron-n6310-s: Move common nodes to a separate file

On Wed, Oct 16, 2019 at 03:07:25PM +, Schrempf Frieder wrote: > From: Frieder Schrempf > > The baseboard for the Kontron N6310 SoM is also used for other SoMs > such as N6311 and N6411. In order to share the code, we move the > definitions of the baseboard to a separate dtsi file. > >

Re: [PATCH 02/10] ARM: dts: Add support for two more Kontron SoMs N6311 and N6411

On Wed, Oct 16, 2019 at 03:07:21PM +, Schrempf Frieder wrote: > From: Frieder Schrempf > > The N6311 and the N6411 SoM are similar to the Kontron N6310 SoM. > They are pin-compatible, but feature a larger RAM and NAND flash > (512MiB instead of 256MiB). Further, the N6411 has an i.MX6ULL

Re: [PATCH 01/10] ARM: dts: imx6ul-kontron-n6310: Move common SoM nodes to a separate file

On Wed, Oct 16, 2019 at 03:07:19PM +, Schrempf Frieder wrote: > From: Frieder Schrempf > > The Kontron N6311 and N6411 SoMs are very similar to N6310. In > preparation to add support for them, we move the common nodes to a > separate file imx6ul-kontron-n6x1x-som-common.dtsi. > >

Re: [PATCH v3 0/4] perf script python: add Python3 support

Em Mon, Mar 11, 2019 at 09:27:07AM +, Hunter, Adrian escreveu: > > From: Tony Jones [mailto:to...@suse.de] > > Once these are applied I believe this is everything needed to run on a > > system > > without Python2. > All look fine to me. Here is my ack as needed: > Acked-by: Adrian Hunter

Re: [PATCH 2/2] percpu: pcpu_next_md_free_region: inclusive check for PCPU_BITMAP_BLOCK_BITS

Hi Peng, On Mon, Mar 04, 2019 at 10:33:55AM +, Peng Fan wrote: > If the block [contig_hint_start, contig_hint_start + contig_hint) > matches block->right_free area, need use "<=", not "<". > > Signed-off-by: Peng Fan > --- > > V1: > Based on https://patchwork.kernel.org/cover/10832459/

Re: [RFC] percpu: decrease pcpu_nr_slots by 1

On Sun, Feb 24, 2019 at 09:17:08AM +, Peng Fan wrote: > Entry pcpu_slot[pcpu_nr_slots - 2] is wasted with current code logic. > pcpu_nr_slots is calculated with `__pcpu_size_to_slot(size) + 2`. > Take pcpu_unit_size as 1024 for example, __pcpu_size_to_slot will > return max(11 -

Re: [PATCH 2/2] percpu: km: no need to consider pcpu_group_offsets[0]

On Sun, Feb 24, 2019 at 01:13:50PM +, Peng Fan wrote: > percpu-km is used on UP systems which only has one group, > so the group offset will be always 0, there is no need > to subtract pcpu_group_offsets[0] when assigning chunk->base_addr > > Signed-off-by: Peng Fan > --- > mm/percpu-km.c |

Re: [CFT][PATCH] kernfs: Correct kernfs directory seeks.

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

Re: [CFT][PATCH] kernfs: Correct kernfs directory seeks.

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

Re: [RESEND PATCH v2] kernfs: fix dentry unexpected skip

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

Re: [RESEND PATCH v2] kernfs: fix dentry unexpected skip

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

Re: [RESEND PATCH v2] kernfs: fix dentry unexpected skip

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

Re: [RESEND PATCH v2] kernfs: fix dentry unexpected skip

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

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

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

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 >

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

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 >

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

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

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

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

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

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. > > > > +*/ > >

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

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. > > > > +*/ > >

Re: [PATCH 5/7] block: Remove superflous rcu_read_[un]lock_sched() in blk_queue_enter()

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

Re: [PATCH 5/7] block: Remove superflous rcu_read_[un]lock_sched() in blk_queue_enter()

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

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

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

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

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

Re: [PATCH 5/8] blk-mq: make blk_abort_request() trigger timeout path

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(>gstate_seq), write_seqcount_end(>gstate_seq) > and preempt_enable(). I think it's fine that the above req->deadline store > does not have that

Re: [PATCH 5/8] blk-mq: make blk_abort_request() trigger timeout path

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(>gstate_seq), write_seqcount_end(>gstate_seq) > and preempt_enable(). I think it's fine that the above req->deadline store > does not have that

Re: [PATCH 3/8] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH 3/8] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH 3/8] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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); > > +

Re: [PATCH 3/8] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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); > > +

Re: [PATCHSET v2] blk-mq: reimplement timeout handling

sed while testing earlier versions. http://lkml.kernel.org/r/20171216120726.517153-1...@kernel.org Thanks. -- tejun

Re: [PATCHSET v2] blk-mq: reimplement timeout handling

sed while testing earlier versions. http://lkml.kernel.org/r/20171216120726.517153-1...@kernel.org Thanks. -- tejun

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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); > >

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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); > >

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH 4/6] blk-mq: make blk_abort_request() trigger timeout path

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) { > > -

Re: [PATCH 4/6] blk-mq: make blk_abort_request() trigger timeout path

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) { > > -

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH 1/6] blk-mq: protect completion path with RCU

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)) > > +

Re: [PATCH 1/6] blk-mq: protect completion path with RCU

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)) > > +

Re: [PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED

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 >

Re: [PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED

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 >

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

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

Re: [PATCH V3 0/6] event synthesization multithreading for perf record

Em Mon, Oct 23, 2017 at 01:43:39PM +, Liang, Kan escreveu: > The plan is to do the multithreading step by step from the simplest case. > Synthesizing stage is just a start. > Only for synthesizing stage, I think the patch series should already cover > all the > 'synthesizing' steps which

Re: [PATCH V3 0/6] event synthesization multithreading for perf record

Em Mon, Oct 23, 2017 at 01:43:39PM +, Liang, Kan escreveu: > The plan is to do the multithreading step by step from the simplest case. > Synthesizing stage is just a start. > Only for synthesizing stage, I think the patch series should already cover > all the > 'synthesizing' steps which

Re: net/sunrpc: v4.14-rc4 lockdep warning

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

Re: net/sunrpc: v4.14-rc4 lockdep warning

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

Re: net/sunrpc: v4.14-rc4 lockdep warning

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

Re: net/sunrpc: v4.14-rc4 lockdep warning

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

Re: [PATCH RFC V4 5/6] perf top: switch to backward overwrite mode

Em Mon, Oct 02, 2017 at 05:19:41PM +, Liang, Kan escreveu: > > > > On Fri, Sep 29, 2017 at 07:47:56AM -0700, kan.li...@intel.com wrote: > > > From: Kan Liang > > > > > > perf_top__mmap_read has severe performance issue in Knights > > > Landing/Mill, when monitoring in

Re: [PATCH RFC V4 5/6] perf top: switch to backward overwrite mode

Em Mon, Oct 02, 2017 at 05:19:41PM +, Liang, Kan escreveu: > > > > On Fri, Sep 29, 2017 at 07:47:56AM -0700, kan.li...@intel.com wrote: > > > From: Kan Liang > > > > > > perf_top__mmap_read has severe performance issue in Knights > > > Landing/Mill, when monitoring in heavy load system. It

Re: [PATCH v1] perf vendor events: Add mapping for KnightsMill PMU events

Em Wed, Mar 01, 2017 at 09:58:41AM +, Wachowski, Karol escreveu: > On Monday, February 20, 2017 12:51 PM +0100, Karol Wachowski wrote: > > Reuse events from KnightsLanding for KnightsMill > > +++ b/tools/perf/pmu-events/arch/x86/mapfile.csv > > @@ -17,6 +17,7 @@

Re: [PATCH v1] perf vendor events: Add mapping for KnightsMill PMU events

Em Wed, Mar 01, 2017 at 09:58:41AM +, Wachowski, Karol escreveu: > On Monday, February 20, 2017 12:51 PM +0100, Karol Wachowski wrote: > > Reuse events from KnightsLanding for KnightsMill > > +++ b/tools/perf/pmu-events/arch/x86/mapfile.csv > > @@ -17,6 +17,7 @@

[PATCH] pata_octeon_cf: remove unused local variables from octeon_cf_set_piomode()

>From d786b91f422c6ad4c0d9bb9c1bef2dd5008e3d9d Mon Sep 17 00:00:00 2001 From: Tejun Heo <t...@kernel.org> 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 <t...@kernel.org> Reported-by: David

[PATCH] pata_octeon_cf: remove unused local variables from octeon_cf_set_piomode()

>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.

Re: [PATCH] perf diff: bug fix, donot overwrite valid build id

Em Mon, Dec 19, 2016 at 02:53:30PM +, Liang, Kan escreveu: > Hi Arnaldo, > > Ping > > Are you OK with the fix? Yeah, looks ok, will merge it. - Arnaldo > Thanks, > Kan > > > > > From: Kan Liang > > > > Fixes a perf diff regression issue which was introduced by

Re: [PATCH] perf diff: bug fix, donot overwrite valid build id

Em Mon, Dec 19, 2016 at 02:53:30PM +, Liang, Kan escreveu: > Hi Arnaldo, > > Ping > > Are you OK with the fix? Yeah, looks ok, will merge it. - Arnaldo > Thanks, > Kan > > > > > From: Kan Liang > > > > Fixes a perf diff regression issue which was introduced by commit > > 5baecbcd9c9a

Re: [PATCH] perf tools: ignore zombie process for user profile

Em Wed, Dec 14, 2016 at 06:26:02PM +, Liang, Kan escreveu: > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > From: Kan Liang > > > Zombie process is dead process. It is meaningless to profile it. > > > It's better to ignore it for user

Re: [PATCH] perf tools: ignore zombie process for user profile

Em Wed, Dec 14, 2016 at 06:26:02PM +, Liang, Kan escreveu: > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > From: Kan Liang > > > Zombie process is dead process. It is meaningless to profile it. > > > It's better to ignore it for user profile. > > I recently

  1   2   >