* Re: PATCH scripts/kernel-doc
From: Jonathan Corbet @ 2018-07-23 15:32 UTC (permalink / raw)
To: valdis.kletnieks; +Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel
In-Reply-To: <50400.1531846649@turing-police.cc.vt.edu>
On Tue, 17 Jul 2018 12:57:29 -0400
valdis.kletnieks@vt.edu wrote:
> Fix a warning whinge from Perl introduced by "scripts: kernel-doc: parse next structs/unions"
>
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE [^\{\}]*})/ at ./scripts/kernel-doc line 1155.
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE )/ at ./scripts/kernel-doc line 1179.
Applied, thanks.
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PATCH scripts/kernel-doc
From: Jonathan Corbet @ 2018-07-23 15:32 UTC (permalink / raw)
To: valdis.kletnieks; +Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel
In-Reply-To: <50400.1531846649@turing-police.cc.vt.edu>
On Tue, 17 Jul 2018 12:57:29 -0400
valdis.kletnieks@vt.edu wrote:
> Fix a warning whinge from Perl introduced by "scripts: kernel-doc: parse next structs/unions"
>
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE [^\{\}]*})/ at ./scripts/kernel-doc line 1155.
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE )/ at ./scripts/kernel-doc line 1179.
Applied, thanks.
jon
^ permalink raw reply
* [PATCH net-next 0/2] be2net: patch-set
From: Suresh Reddy @ 2018-07-23 14:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <Suresh.Reddy@broadcom.com>
Hi Dave, Please consider applying these two patches to net-next
Suresh Reddy (2):
be2net: Collect the transmit queue data in Tx timeout
be2net: Update the driver version to 12.0.0.0
drivers/net/ethernet/emulex/benet/be.h | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 80 ++++++++++++++++++++++++++++-
2 files changed, 80 insertions(+), 2 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH net-next 2/2] be2net: Update the driver version to 12.0.0.0
From: Suresh Reddy @ 2018-07-23 14:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <20180723142524.24224-1-suresh.reddy@broadcom.com>
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
---
drivers/net/ethernet/emulex/benet/be.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 7005949..d80fe03 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -37,7 +37,7 @@
#include "be_hw.h"
#include "be_roce.h"
-#define DRV_VER "11.4.0.0"
+#define DRV_VER "12.0.0.0"
#define DRV_NAME "be2net"
#define BE_NAME "Emulex BladeEngine2"
#define BE3_NAME "Emulex BladeEngine3"
--
2.10.1
^ permalink raw reply related
* [PATCH net-next 1/2] be2net: Collect the transmit queue data in Tx timeout
From: Suresh Reddy @ 2018-07-23 14:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <20180723142524.24224-1-suresh.reddy@broadcom.com>
Driver dumps tx_queue, tx_compl, pending SKBs information in tx_timeout.
This debug data used to idenfiy the cause of the time out.
Also reset Lancer chip in tx_timeout.
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 80 ++++++++++++++++++++++++++++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 05e4c0b..580cdec 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1412,6 +1412,83 @@ static netdev_tx_t be_xmit(struct sk_buff *skb, struct net_device *netdev)
return NETDEV_TX_OK;
}
+static void be_tx_timeout(struct net_device *netdev)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+ struct device *dev = &adapter->pdev->dev;
+ struct be_tx_obj *txo;
+ struct sk_buff *skb;
+ struct tcphdr *tcphdr;
+ struct udphdr *udphdr;
+ u32 *entry;
+ int status;
+ int i, j;
+
+ for_all_tx_queues(adapter, txo, i) {
+ dev_info(dev, "TXQ Dump: %d H: %d T: %d used: %d, qid: 0x%x\n",
+ i, txo->q.head, txo->q.tail,
+ atomic_read(&txo->q.used), txo->q.id);
+
+ entry = txo->q.dma_mem.va;
+ for (j = 0; j < TX_Q_LEN * 4; j += 4) {
+ if (entry[j] != 0 || entry[j + 1] != 0 ||
+ entry[j + 2] != 0 || entry[j + 3] != 0) {
+ dev_info(dev, "Entry %d 0x%x 0x%x 0x%x 0x%x\n",
+ j, entry[j], entry[j + 1],
+ entry[j + 2], entry[j + 3]);
+ }
+ }
+
+ entry = txo->cq.dma_mem.va;
+ dev_info(dev, "TXCQ Dump: %d H: %d T: %d used: %d\n",
+ i, txo->cq.head, txo->cq.tail,
+ atomic_read(&txo->cq.used));
+ for (j = 0; j < TX_CQ_LEN * 4; j += 4) {
+ if (entry[j] != 0 || entry[j + 1] != 0 ||
+ entry[j + 2] != 0 || entry[j + 3] != 0) {
+ dev_info(dev, "Entry %d 0x%x 0x%x 0x%x 0x%x\n",
+ j, entry[j], entry[j + 1],
+ entry[j + 2], entry[j + 3]);
+ }
+ }
+
+ for (j = 0; j < TX_Q_LEN; j++) {
+ if (txo->sent_skb_list[j]) {
+ skb = txo->sent_skb_list[j];
+ if (ip_hdr(skb)->protocol == IPPROTO_TCP) {
+ tcphdr = tcp_hdr(skb);
+ dev_info(dev, "TCP source port %d\n",
+ ntohs(tcphdr->source));
+ dev_info(dev, "TCP dest port %d\n",
+ ntohs(tcphdr->dest));
+ dev_info(dev, "TCP seqence num %d\n",
+ ntohs(tcphdr->seq));
+ dev_info(dev, "TCP ack_seq %d\n",
+ ntohs(tcphdr->ack_seq));
+ } else if (ip_hdr(skb)->protocol ==
+ IPPROTO_UDP) {
+ udphdr = udp_hdr(skb);
+ dev_info(dev, "UDP source port %d\n",
+ ntohs(udphdr->source));
+ dev_info(dev, "UDP dest port %d\n",
+ ntohs(udphdr->dest));
+ }
+ dev_info(dev, "skb[%d] %p len %d proto 0x%x\n",
+ j, skb, skb->len, skb->protocol);
+ }
+ }
+ }
+
+ if (lancer_chip(adapter)) {
+ dev_info(dev, "Initiating reset due to tx timeout\n");
+ dev_info(dev, "Resetting adapter\n");
+ status = lancer_physdev_ctrl(adapter,
+ PHYSDEV_CONTROL_FW_RESET_MASK);
+ if (status)
+ dev_err(dev, "Reset failed .. Reboot server\n");
+ }
+}
+
static inline bool be_in_all_promisc(struct be_adapter *adapter)
{
return (adapter->if_flags & BE_IF_FLAGS_ALL_PROMISCUOUS) ==
@@ -3274,7 +3351,7 @@ void be_detect_error(struct be_adapter *adapter)
/* Do not log error messages if its a FW reset */
if (sliport_err1 == SLIPORT_ERROR_FW_RESET1 &&
sliport_err2 == SLIPORT_ERROR_FW_RESET2) {
- dev_info(dev, "Firmware update in progress\n");
+ dev_info(dev, "Reset is in progress\n");
} else {
dev_err(dev, "Error detected in the card\n");
dev_err(dev, "ERR: sliport status 0x%x\n",
@@ -5218,6 +5295,7 @@ static const struct net_device_ops be_netdev_ops = {
.ndo_get_vf_config = be_get_vf_config,
.ndo_set_vf_link_state = be_set_vf_link_state,
.ndo_set_vf_spoofchk = be_set_vf_spoofchk,
+ .ndo_tx_timeout = be_tx_timeout,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = be_netpoll,
#endif
--
2.10.1
^ permalink raw reply related
* Re: [stable-4.14 01/23] blk-mq-sched: move actual dispatching into one helper
From: Jens Axboe @ 2018-07-23 14:31 UTC (permalink / raw)
To: Jack Wang, gregkh, stable; +Cc: Ming Lei, Jack Wang
In-Reply-To: <1532352285-13589-2-git-send-email-jinpuwang@gmail.com>
On 7/23/18 7:24 AM, Jack Wang wrote:
> From: Ming Lei <ming.lei@redhat.com>
>
> commit caf8eb0d604a0eaeb8111eb4d36853a6d08eebe7 upstream
>
> So that it becomes easy to support to dispatch from sw queue in the
> following patch.
>
> No functional change.
What is this huge series of 23 patches?!
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2 00/19] Fixes for sched/numa_balancing
From: Rik van Riel @ 2018-07-23 15:33 UTC (permalink / raw)
To: Srikar Dronamraju, Peter Zijlstra
Cc: Ingo Molnar, LKML, Mel Gorman, Thomas Gleixner
In-Reply-To: <20180723150954.GI30345@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
On Mon, 2018-07-23 at 08:09 -0700, Srikar Dronamraju wrote:
> * Peter Zijlstra <peterz@infradead.org> [2018-07-23 15:57:00]:
>
> > On Wed, Jun 20, 2018 at 10:32:41PM +0530, Srikar Dronamraju wrote:
> > > Srikar Dronamraju (19):
> >
> > > sched/numa: Stop multiple tasks from moving to the cpu at the
> > > same time
>
> This patch has go-ahead from Mel and Rik and no outstanding comments.
>
> In my analysis, I did find a lot of cases where the same cpu ended up
> being the target. + I am not sure you can apply "sched/numa: Restrict
> migrating in parallel to the same node" cleanly without this patch.
>
> So I am a bit confused. If possible, please clarify.
I believe that patch fixes a real issue, but it would
be nice if the code could be documented better so it
does not confuse people who look at the code later.
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] timekeeping.txt: Correct maxCount of n-bit binary counter
From: Jonathan Corbet @ 2018-07-23 15:33 UTC (permalink / raw)
To: Siddaraju DH; +Cc: john.stultz, tglx, linux-kernel, linux-doc
In-Reply-To: <20180719163651.19360-1-siddarajudh@gmail.com>
On Thu, 19 Jul 2018 22:06:51 +0530
Siddaraju DH <siddarajudh@gmail.com> wrote:
> A n-bit binary counter can count a maximum of 2^n events and the count
> value ranges from 0 to (2^n)-1
>
> Signed-off-by: Siddaraju DH <siddarajudh@gmail.com>
Applied, thanks.
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v6 0/5] add mailbox support for i.MX7D
From: Jassi Brar @ 2018-07-23 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM0PR04MB4211B82FD69B41B27465F5E580570@AM0PR04MB4211.eurprd04.prod.outlook.com>
On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> Hi Oleksij,
>
> Thanks for the work.
>
> Hi Jassi,
> Do you think if we can have your tag and let those patches go through
> Shawn's tree as the later QXP support patches depends on them?
>
Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
Dong Aisheng (2):
dt-bindings: mailbox: allow mbox-cells to be equal to 0
dt-bindings: arm: fsl: add mu binding doc
Oleksij Rempel (3):
dt-bindings: mailbox: imx-mu: add generic MU channel support
ARM: dts: imx7s: add i.MX7 messaging unit support
mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
* Re: [PATCH v6 0/5] add mailbox support for i.MX7D
From: Jassi Brar @ 2018-07-23 15:33 UTC (permalink / raw)
To: A.s. Dong
Cc: Mark Rutland, devicetree@vger.kernel.org, Vladimir Zapolskiy,
Oleksij Rempel, Rob Herring, dl-linux-imx, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB4211B82FD69B41B27465F5E580570@AM0PR04MB4211.eurprd04.prod.outlook.com>
On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> Hi Oleksij,
>
> Thanks for the work.
>
> Hi Jassi,
> Do you think if we can have your tag and let those patches go through
> Shawn's tree as the later QXP support patches depends on them?
>
Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
Dong Aisheng (2):
dt-bindings: mailbox: allow mbox-cells to be equal to 0
dt-bindings: arm: fsl: add mu binding doc
Oleksij Rempel (3):
dt-bindings: mailbox: imx-mu: add generic MU channel support
ARM: dts: imx7s: add i.MX7 messaging unit support
mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
* Re: [PATCH] timekeeping.txt: Correct maxCount of n-bit binary counter
From: Jonathan Corbet @ 2018-07-23 15:33 UTC (permalink / raw)
To: Siddaraju DH; +Cc: john.stultz, tglx, linux-kernel, linux-doc
In-Reply-To: <20180719163651.19360-1-siddarajudh@gmail.com>
On Thu, 19 Jul 2018 22:06:51 +0530
Siddaraju DH <siddarajudh@gmail.com> wrote:
> A n-bit binary counter can count a maximum of 2^n events and the count
> value ranges from 0 to (2^n)-1
>
> Signed-off-by: Siddaraju DH <siddarajudh@gmail.com>
Applied, thanks.
jon
^ permalink raw reply
* [PATCH v3] mmc: sunxi: remove output of virtual base address
From: Andre Przywara @ 2018-07-23 15:34 UTC (permalink / raw)
To: Ulf Hansson
Cc: Maxime Ripard, Chen-Yu Tsai, Robin Murphy,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Recent Linux versions refuse to print actual virtual kernel addresses,
to not give a hint about the location of the kernel in a randomized virtual
address space. This affects the output of the sunxi MMC controller
driver, which now produces the rather uninformative line:
[ 1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8
Since the virtual base address is not really interesting in the first
place, let's just drop this value. The same applies to Linux' notion of
the interrupt number, which is independent from the GIC SPI number.
We have the physical address as part of the DT node name, which is way
more useful for debugging purposes.
To keep a success message in the driver, we make this purpose explicit
with the word "initialized", plus print some information that is not too
obvious and that we learned while probing the device:
the maximum request size and whether it uses the new timing mode.
So the output turns into:
[ 1.750626] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[ 1.786699] sunxi-mmc 1c11000.mmc: initialized, max. request size: 2048 KB
Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
---
drivers/mmc/host/sunxi-mmc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 8e7f3e35ee3d..c18cf035ac00 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1407,7 +1407,10 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
if (ret)
goto error_free_dma;
- dev_info(&pdev->dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
+ dev_info(&pdev->dev, "initialized, max. request size: %u KB%s\n",
+ mmc->max_req_size >> 10,
+ host->use_new_timings ? ", uses new timings mode" : "");
+
return 0;
error_free_dma:
--
2.14.4
^ permalink raw reply related
* [PATCH v3] mmc: sunxi: remove output of virtual base address
From: Andre Przywara @ 2018-07-23 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Recent Linux versions refuse to print actual virtual kernel addresses,
to not give a hint about the location of the kernel in a randomized virtual
address space. This affects the output of the sunxi MMC controller
driver, which now produces the rather uninformative line:
[ 1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8
Since the virtual base address is not really interesting in the first
place, let's just drop this value. The same applies to Linux' notion of
the interrupt number, which is independent from the GIC SPI number.
We have the physical address as part of the DT node name, which is way
more useful for debugging purposes.
To keep a success message in the driver, we make this purpose explicit
with the word "initialized", plus print some information that is not too
obvious and that we learned while probing the device:
the maximum request size and whether it uses the new timing mode.
So the output turns into:
[ 1.750626] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[ 1.786699] sunxi-mmc 1c11000.mmc: initialized, max. request size: 2048 KB
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/mmc/host/sunxi-mmc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 8e7f3e35ee3d..c18cf035ac00 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1407,7 +1407,10 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
if (ret)
goto error_free_dma;
- dev_info(&pdev->dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
+ dev_info(&pdev->dev, "initialized, max. request size: %u KB%s\n",
+ mmc->max_req_size >> 10,
+ host->use_new_timings ? ", uses new timings mode" : "");
+
return 0;
error_free_dma:
--
2.14.4
^ permalink raw reply related
* Re: [PATCH 02/10] mm: workingset: tell cache transitions from workingset thrashing
From: Arnd Bergmann @ 2018-07-23 15:35 UTC (permalink / raw)
To: Johannes Weiner
Cc: Peter Zijlstra, Suren Baghdasaryan, Mike Galbraith, Will Deacon,
Linux Kernel Mailing List, kernel-team, Linux-MM, Vinayak Menon,
Ingo Molnar, Shakeel Butt, Catalin Marinas, Tejun Heo, cgroups,
Andrew Morton, Linus Torvalds, Christopher Lameter, Linux ARM
In-Reply-To: <20180723152323.GA3699@cmpxchg.org>
On Mon, Jul 23, 2018 at 5:23 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> On Mon, Jul 23, 2018 at 03:36:09PM +0200, Arnd Bergmann wrote:
>> On Thu, Jul 12, 2018 at 7:29 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
>> In file included from /git/arm-soc/include/linux/kernel.h:10,
>> from /git/arm-soc/arch/arm64/mm/init.c:20:
>> /git/arm-soc/arch/arm64/mm/init.c: In function 'mem_init':
>> /git/arm-soc/include/linux/compiler.h:357:38: error: call to
>> '__compiletime_assert_618' declared with attribute error: BUILD_BUG_ON
>> failed: sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT)
>
> This BUILD_BUG_ON() is to make sure we're sizing the VMEMMAP struct
> page array properly (address space divided by struct page size).
>
> From the code:
>
> /*
> * Log2 of the upper bound of the size of a struct page. Used for sizing
> * the vmemmap region only, does not affect actual memory footprint.
> * We don't use sizeof(struct page) directly since taking its size here
> * requires its definition to be available at this point in the inclusion
> * chain, and it may not be a power of 2 in the first place.
> */
> #define STRUCT_PAGE_MAX_SHIFT 6
>
...
> However, the check isn't conditional on that config option. And when
> VMEMMAP is disabled, we need 22 additional bits to identify the sparse
> memory sections in page->flags as well:
>
>> CONFIG_NODES_SHIFT=2
>> # CONFIG_ARCH_USES_PG_UNCACHED is not set
>> CONFIG_MEMORY_FAILURE=y
>> CONFIG_IDLE_PAGE_TRACKING=y
>>
>> #define MAX_NR_ZONES 3
>> #define ZONES_SHIFT 2
>> #define MAX_PHYSMEM_BITS 52
>> #define SECTION_SIZE_BITS 30
>> #define SECTIONS_WIDTH 22
>
> ^^^ Those we get back with VMEMMAP enabled.
>
> So for configs for which the check is intended, it passes. We just
> need to make it conditional to those.
Ok, thanks for the analysis, I had missed that and was about to
send a different patch to increase STRUCT_PAGE_MAX_SHIFT
in some configurations, which is not as good.
> From 1d24635a6c7cd395bad5c29a3b9e5d2e98d9ab84 Mon Sep 17 00:00:00 2001
> From: Johannes Weiner <hannes@cmpxchg.org>
> Date: Mon, 23 Jul 2018 10:18:23 -0400
> Subject: [PATCH] arm64: fix vmemmap BUILD_BUG_ON() triggering on !vmemmap
> setups
>
> Arnd reports the following arm64 randconfig build error with the PSI
> patches that add another page flag:
>
You could add further text here that I had just added to my
patch description (not sent):
Further experiments show that the build error already existed before,
but was only triggered with larger values of CONFIG_NR_CPU and/or
CONFIG_NODES_SHIFT that might be used in actual configurations but
not in randconfig builds.
With longer CPU and node masks, I could recreate the problem with
kernels as old as linux-4.7 when arm64 NUMA support got added.
Cc: stable@vger.kernel.org
Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
Fixes: 3e1907d5bf5a ("arm64: mm: move vmemmap region right below
the linear region")
> arch/arm64/mm/init.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 1b18b4722420..72c9b6778b0a 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -611,11 +611,13 @@ void __init mem_init(void)
> BUILD_BUG_ON(TASK_SIZE_32 > TASK_SIZE_64);
> #endif
>
> +#ifndef CONFIG_SPARSEMEM_VMEMMAP
> /*
I tested it on two broken configurations, and found that you have
a typo here, it should be 'ifdef', not 'ifndef'. With that change, it
seems to build fine.
Tested-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* [PATCH 02/10] mm: workingset: tell cache transitions from workingset thrashing
From: Arnd Bergmann @ 2018-07-23 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723152323.GA3699@cmpxchg.org>
On Mon, Jul 23, 2018 at 5:23 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> On Mon, Jul 23, 2018 at 03:36:09PM +0200, Arnd Bergmann wrote:
>> On Thu, Jul 12, 2018 at 7:29 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
>> In file included from /git/arm-soc/include/linux/kernel.h:10,
>> from /git/arm-soc/arch/arm64/mm/init.c:20:
>> /git/arm-soc/arch/arm64/mm/init.c: In function 'mem_init':
>> /git/arm-soc/include/linux/compiler.h:357:38: error: call to
>> '__compiletime_assert_618' declared with attribute error: BUILD_BUG_ON
>> failed: sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT)
>
> This BUILD_BUG_ON() is to make sure we're sizing the VMEMMAP struct
> page array properly (address space divided by struct page size).
>
> From the code:
>
> /*
> * Log2 of the upper bound of the size of a struct page. Used for sizing
> * the vmemmap region only, does not affect actual memory footprint.
> * We don't use sizeof(struct page) directly since taking its size here
> * requires its definition to be available at this point in the inclusion
> * chain, and it may not be a power of 2 in the first place.
> */
> #define STRUCT_PAGE_MAX_SHIFT 6
>
...
> However, the check isn't conditional on that config option. And when
> VMEMMAP is disabled, we need 22 additional bits to identify the sparse
> memory sections in page->flags as well:
>
>> CONFIG_NODES_SHIFT=2
>> # CONFIG_ARCH_USES_PG_UNCACHED is not set
>> CONFIG_MEMORY_FAILURE=y
>> CONFIG_IDLE_PAGE_TRACKING=y
>>
>> #define MAX_NR_ZONES 3
>> #define ZONES_SHIFT 2
>> #define MAX_PHYSMEM_BITS 52
>> #define SECTION_SIZE_BITS 30
>> #define SECTIONS_WIDTH 22
>
> ^^^ Those we get back with VMEMMAP enabled.
>
> So for configs for which the check is intended, it passes. We just
> need to make it conditional to those.
Ok, thanks for the analysis, I had missed that and was about to
send a different patch to increase STRUCT_PAGE_MAX_SHIFT
in some configurations, which is not as good.
> From 1d24635a6c7cd395bad5c29a3b9e5d2e98d9ab84 Mon Sep 17 00:00:00 2001
> From: Johannes Weiner <hannes@cmpxchg.org>
> Date: Mon, 23 Jul 2018 10:18:23 -0400
> Subject: [PATCH] arm64: fix vmemmap BUILD_BUG_ON() triggering on !vmemmap
> setups
>
> Arnd reports the following arm64 randconfig build error with the PSI
> patches that add another page flag:
>
You could add further text here that I had just added to my
patch description (not sent):
Further experiments show that the build error already existed before,
but was only triggered with larger values of CONFIG_NR_CPU and/or
CONFIG_NODES_SHIFT that might be used in actual configurations but
not in randconfig builds.
With longer CPU and node masks, I could recreate the problem with
kernels as old as linux-4.7 when arm64 NUMA support got added.
Cc: stable at vger.kernel.org
Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
Fixes: 3e1907d5bf5a ("arm64: mm: move vmemmap region right below
the linear region")
> arch/arm64/mm/init.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 1b18b4722420..72c9b6778b0a 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -611,11 +611,13 @@ void __init mem_init(void)
> BUILD_BUG_ON(TASK_SIZE_32 > TASK_SIZE_64);
> #endif
>
> +#ifndef CONFIG_SPARSEMEM_VMEMMAP
> /*
I tested it on two broken configurations, and found that you have
a typo here, it should be 'ifdef', not 'ifndef'. With that change, it
seems to build fine.
Tested-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply
* ✓ Fi.CI.BAT: success for drm/i915: Skip repeated calls to i915_gem_set_wedged()
From: Patchwork @ 2018-07-23 15:35 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged()
URL : https://patchwork.freedesktop.org/series/47067/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4528 -> Patchwork_9747 =
== Summary - SUCCESS ==
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47067/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9747 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@gem_ctx_create@basic-files:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719)
igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
fi-skl-guc: PASS -> FAIL (fdo#103191)
==== Possible fixes ====
igt@drv_module_reload@basic-no-display:
fi-glk-j4005: DMESG-WARN (fdo#106725) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-ivb-3520m: FAIL (fdo#103375) -> PASS
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
== Participating hosts (48 -> 43) ==
Additional (1): fi-kbl-8809g
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510
== Build changes ==
* Linux: CI_DRM_4528 -> Patchwork_9747
CI_DRM_4528: 9e2763473a5f24fa8848e5508cae60c3b5af3cf3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4571: 65fccc149b85968cdce4737266b056059c1510f3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9747: 8c8dac2e80e2deaa195e17732c979a8949325c01 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8c8dac2e80e2 drm/i915: Skip repeated calls to i915_gem_set_wedged()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9747/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] memory: jz4780-nemc: build depend on OF
From: Randy Dunlap @ 2018-07-23 15:35 UTC (permalink / raw)
To: Corentin Labbe, Zubair.Kakakhel, gregkh, alex; +Cc: linux-kernel
In-Reply-To: <1532345923-28811-1-git-send-email-clabbe@baylibre.com>
On 07/23/2018 04:38 AM, Corentin Labbe wrote:
> jz4780-nemc use of_ functions, so it needs to depend on OF
>
> This fix the following build failure on x86
> drivers/memory/jz4780-nemc.c: In function ‘jz4780_nemc_num_banks’:
> drivers/memory/jz4780-nemc.c:72:10: error: implicit declaration of function ‘of_read_number’ [-Werror=implicit-function-declaration]
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> drivers/memory/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index a642552..faa1a23 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -124,6 +124,7 @@ config JZ4780_NEMC
> default y
> depends on MACH_JZ4780 || COMPILE_TEST
> depends on HAS_IOMEM
> + depends on OF
> help
> This driver is for the NAND/External Memory Controller (NEMC) in
> the Ingenic JZ4780. This controller is used to handle external
>
Duplicate of https://lore.kernel.org/lkml/20180721200049.7553-1-anders.roxell@linaro.org/
--
~Randy
^ permalink raw reply
* [Bug 107333] Display Not Detected If Powered Off When amdgpu.dc=1
From: bugzilla-daemon @ 2018-07-23 15:36 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-107333-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 430 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=107333
--- Comment #2 from Benjamin Hodgetts <ben@xnode.org> ---
By "forced" I mean I specified amdgpu.dc=0 on the kernel command line to force
DC off (as it's on by default).
Yes to the second part of your question. Using dc=0 allows the display to be
properly detected, even if it's turned off.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] IB/mlx5: avoid binding a new mpi unit to the same devices repeatedly
From: Qing Huang @ 2018-07-23 15:36 UTC (permalink / raw)
To: Daniel Jurgens, Or Gerlitz, Parav Pandit
Cc: Linux Kernel, RDMA mailing list, Jason Gunthorpe, Doug Ledford,
Leon Romanovsky, gerald.gibson
In-Reply-To: <dc4d502c-bc3c-46e3-a984-41271951a5f7@mellanox.com>
On 7/15/2018 12:48 PM, Daniel Jurgens wrote:
> On 7/14/2018 10:57 AM, Or Gerlitz wrote:
>> On Sat, Jul 14, 2018 at 2:50 AM, Qing Huang <qing.huang@oracle.com> wrote:
>>> When a CX5 device is configured in dual-port RoCE mode, after creating
>>> many VFs against port 1, creating the same number of VFs against port 2
>>> will flood kernel/syslog with something like
>>> "mlx5_*:mlx5_ib_bind_slave_port:4266:(pid 5269): port 2 already
>>> affiliated."
>>>
>>> So basically, when traversing mlx5_ib_dev_list, mlx5_ib_add_slave_port()
>>> shouldn't repeatedly attempt to bind the new mpi data unit to every device
>>> on the list until it finds an unbound device.
>> Daniel,
>>
>> What is mpi data unit?
> It's a structure to keep track affiliated port info in dual port RoCE mode, mpi meaning multi-port info. Parav can review this it my absence, otherwise I can take a closer look when I return to the office.
Hi Daniel/Parav,
Have you got a chance to review this patch? Thanks!
>> Or.
>>
>>> Reported-by: Gerald Gibson <gerald.gibson@oracle.com>
>>> Signed-off-by: Qing Huang <qing.huang@oracle.com>
>>> ---
>>> drivers/infiniband/hw/mlx5/main.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
>>> index b3ba9a2..1ddd1d3 100644
>>> --- a/drivers/infiniband/hw/mlx5/main.c
>>> +++ b/drivers/infiniband/hw/mlx5/main.c
>>> @@ -6068,7 +6068,8 @@ static void *mlx5_ib_add_slave_port(struct mlx5_core_dev *mdev, u8 port_num)
>>>
>>> mutex_lock(&mlx5_ib_multiport_mutex);
>>> list_for_each_entry(dev, &mlx5_ib_dev_list, ib_dev_list) {
>>> - if (dev->sys_image_guid == mpi->sys_image_guid)
>>> + if (dev->sys_image_guid == mpi->sys_image_guid &&
>>> + !dev->port[mlx5_core_native_port_num(mdev) - 1].mp.mpi)
>>> bound = mlx5_ib_bind_slave_port(dev, mpi);
>>>
>>> if (bound) {
>>> --
>>> 2.9.3
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-23 14:34 UTC (permalink / raw)
To: Baoquan He
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180719151753.GB7147@localhost.localdomain>
On Thu 19-07-18 23:17:53, Baoquan He wrote:
> Kexec has been a formal feature in our distro, and customers owning
> those kind of very large machine can make use of this feature to speed
> up the reboot process. On uefi machine, the kexec_file loading will
> search place to put kernel under 4G from top to down. As we know, the
> 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> it. It may have possibility to not be able to find a usable space for
> kernel/initrd. From the top down of the whole memory space, we don't
> have this worry.
I do not have the full context here but let me note that you should be
careful when doing top-down reservation because you can easily get into
hotplugable memory and break the hotremove usecase. We even warn when
this is done. See memblock_find_in_range_node
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] zh_CN:translation for block queue into Chinese
From: Jonathan Corbet @ 2018-07-23 15:36 UTC (permalink / raw)
To: Norman; +Cc: linux-doc, harryxiyou, linux-kernel
In-Reply-To: <c10695de-d6aa-bb5a-2635-efd0f6f78269@gmx.com>
On Fri, 20 Jul 2018 10:27:06 +0800
Norman <norman.kern@gmx.com> wrote:
> Translate block/queue-sysfs.txt into Chinese
>
> Signed-off-by: Norman Kern <norman.kern@gmx.com>
> ---
> .../translations/zh_CN/block/queue-sysfs.md | 205
> +++++++++++++++++++++
So...are you translating this into markdown format? Please don't do
that, we don't need another documentation format in the kernel. If you
want to convert this document to structured markup, the ideal approach
would be to convert the source document to RST first, then translate the
result.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: CCREE performance on R-Car H3 + crash
From: Geert Uytterhoeven @ 2018-07-23 14:35 UTC (permalink / raw)
To: Gilad Ben-Yossef; +Cc: Linux-Renesas, Linux Crypto Mailing List
In-Reply-To: <CAOtvUMeU17v=GT3fo8uP0Lt=Wxp6jj4aD_xs87EqTiuxVOkTBA@mail.gmail.com>
Hi Gilad,
On Mon, Jul 23, 2018 at 4:25 PM Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> >> CC linux-crypto for the crash log.
> >>
> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> >>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
> >>> <geert@linux-m68k.org> wrote:
> >>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some small
> > ...
> >>
> >> $ cryptsetup benchmark
> >> # Tests are approximate using memory only (no storage IO).
> >> PBKDF2-sha1 478364 iterations per second for 256-bit key
> >> PBKDF2-sha256 927943 iterations per second for 256-bit key
> >> PBKDF2-sha512 360583 iterations per second for 256-bit key
> >> PBKDF2-ripemd160 266677 iterations per second for 256-bit key
> >> PBKDF2-whirlpool 115787 iterations per second for 256-bit key
> >> # Algorithm | Key | Encryption | Decryption
> >> aes-cbc 128b 46.0 MiB/s 46.7 MiB/s
> >> serpent-cbc 128b N/A N/A
> >> twofish-cbc 128b N/A N/A
> >> aes-cbc 256b 46.5 MiB/s 46.4 MiB/s
> >> serpent-cbc 256b N/A N/A
> >> twofish-cbc 256b N/A N/A
> >> Segmentation fault
> >>
> >> Oops.
> >>
> >> ccree e6601000.crypto: Unsupported data size 65536.
> >> Unable to handle kernel paging request at virtual address ffffffbf5c3c3c20
> >
> > Oy. Thank you for reporting this. I'll take a look at what is going on ASAP.
>
> hmm... well, the plot thickens.
>
> I was able to recreate the "Unsupported data size 65536" message and
> now trying to understand
> why the check that causes it is there but - I wasn't able to get a
> crash, nor do I understand why
> this condition would result in a crash (it ends up returning -EINVAL)... :-(
>
> I am surely using a different tree though - I'm based on the
> cryptodev/master tree with cherry picking of just R-Car ccree clocks
> and enabling.
>
> I was thinking maybe it's a fix that is already in upstream cryptodev
> tree but not in your tree but didn't manage to identify any obvious
> suspects
>
> What tree are you based off?
My tree is based on renesas-drivers-2018-07-17-v4.18-rc5 from
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/
Do you want me to try something different?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [stable-4.14 00/23] block/scsi multiqueue performance enhancement and
From: Jack Wang @ 2018-07-23 15:37 UTC (permalink / raw)
To: Jens Axboe
Cc: Greg Kroah-Hartman, linux-scsi, linux-block, Wang Jinpu, stable,
Jinpu Wang
In-Reply-To: <0c2c50c4-3a17-c0cd-6ece-4f2ca6e30dde@kernel.dk>
Jens Axboe <axboe@kernel.dk> =E4=BA=8E2018=E5=B9=B47=E6=9C=8823=E6=97=A5=E5=
=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=885:31=E5=86=99=E9=81=93=EF=BC=9A
>
> On 7/23/18 9:28 AM, Jack Wang wrote:
> > Jens Axboe <axboe@kernel.dk> =E4=BA=8E2018=E5=B9=B47=E6=9C=8823=E6=97=
=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=885:05=E5=86=99=E9=81=93=EF=BC=9A
> >>
> >> On 7/23/18 9:00 AM, Jack Wang wrote:
> >>> Hi Greg,
> >>>
> >>> Thanks for quick reply. Please see reply inline.
> >>>
> >>>
> >>>
> >>> Greg KH <gregkh@linuxfoundation.org> =E4=BA=8E2018=E5=B9=B47=E6=9C=88=
23=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=883:34=E5=86=99=E9=81=93=EF=
=BC=9A
> >>>>
> >>>> On Mon, Jul 23, 2018 at 03:24:22PM +0200, Jack Wang wrote:
> >>>>> Hi Greg,
> >>>>>
> >>>>> Please consider this patchset, which include block/scsi multiqueue =
performance
> >>>>> enhancement and bugfix.
> >>>>
> >>>> What exactly is the performance enhancement? How can you measure it=
?
> >>>> How did you measure it?
> >>> I'm testing on SRP/IBNBD using fio, I've seen +10% with mix IO load,
> >>> and 50% improvement on small IO (bs=3D512.) with the patchset.
> >>
> >> Big nak on backporting this huge series, it's a lot of core changes.
> >> It's way beyond the scope of a stable fix backport.
> >>
> >> --
> >> Jens Axboe
> >>
> > OK, could you shed light on how could we fix the queue stall problem on=
4.14?
> > My colleague Roman reported to upstream:
> > https://lkml.org/lkml/2017/10/18/263
> >
> > It's still there on latest 4.14.
>
> The proposed patch is a helluva lot simpler than doing a 23 patch selecti=
ve
> backport.
>
> --
> Jens Axboe
>
Do you think it make sense to port Roman's patch to upstream 4.14?
So others would also be benifitial?
On the other side, stable tree only takes patches accepted into Linus tree.
Thanks,
Jack
^ permalink raw reply
* Re: [stable-4.14 00/23] block/scsi multiqueue performance enhancement and
From: Jack Wang @ 2018-07-23 15:37 UTC (permalink / raw)
To: Jens Axboe
Cc: Greg Kroah-Hartman, linux-scsi, linux-block, Wang Jinpu, stable,
Jinpu Wang
In-Reply-To: <0c2c50c4-3a17-c0cd-6ece-4f2ca6e30dde@kernel.dk>
Jens Axboe <axboe@kernel.dk> 于2018年7月23日周一 下午5:31写道：
>
> On 7/23/18 9:28 AM, Jack Wang wrote:
> > Jens Axboe <axboe@kernel.dk> 于2018年7月23日周一 下午5:05写道：
> >>
> >> On 7/23/18 9:00 AM, Jack Wang wrote:
> >>> Hi Greg,
> >>>
> >>> Thanks for quick reply. Please see reply inline.
> >>>
> >>>
> >>>
> >>> Greg KH <gregkh@linuxfoundation.org> 于2018年7月23日周一 下午3:34写道：
> >>>>
> >>>> On Mon, Jul 23, 2018 at 03:24:22PM +0200, Jack Wang wrote:
> >>>>> Hi Greg,
> >>>>>
> >>>>> Please consider this patchset, which include block/scsi multiqueue performance
> >>>>> enhancement and bugfix.
> >>>>
> >>>> What exactly is the performance enhancement? How can you measure it?
> >>>> How did you measure it?
> >>> I'm testing on SRP/IBNBD using fio, I've seen +10% with mix IO load,
> >>> and 50% improvement on small IO (bs=512.) with the patchset.
> >>
> >> Big nak on backporting this huge series, it's a lot of core changes.
> >> It's way beyond the scope of a stable fix backport.
> >>
> >> --
> >> Jens Axboe
> >>
> > OK, could you shed light on how could we fix the queue stall problem on 4.14?
> > My colleague Roman reported to upstream:
> > https://lkml.org/lkml/2017/10/18/263
> >
> > It's still there on latest 4.14.
>
> The proposed patch is a helluva lot simpler than doing a 23 patch selective
> backport.
>
> --
> Jens Axboe
>
Do you think it make sense to port Roman's patch to upstream 4.14?
So others would also be benifitial?
On the other side, stable tree only takes patches accepted into Linus tree.
Thanks,
Jack
^ permalink raw reply
* Re: [PATCH RESEND] kthread, tracing: Don't expose half-written comm when creating kthreads
From: Steven Rostedt @ 2018-07-23 15:37 UTC (permalink / raw)
To: Snild Dolkow
Cc: linux-kernel, Ingo Molnar, Jens Axboe, Tejun Heo,
Greg Kroah-Hartman, Linus Torvalds, Peter Enderborg,
Yoshitaka Seto, Oleksiy Avramchenko, KOSAKI Motohiro, John Stultz
In-Reply-To: <9d762b4e-20a7-578f-90c8-10a044921d67@sony.com>
On Mon, 23 Jul 2018 16:23:09 +0200
Snild Dolkow <snild@sony.com> wrote:
> On 07/23/2018 03:55 PM, Steven Rostedt wrote:
>
> > Can you add a comment here stating something to the affect of:
> > /* task is now visible to other tasks */
> >
> > -- Steve
> Sure, but isn't that a bit misleading? It will have been visible since
> some unknown point in time between waking up kthreadd and the return of
> wait_for_completion(); we're not the ones making it visible.
>
I guess that should be reworded, as that is not what I meant, and I
thought not what I stated. It's stating that the task is now visible,
not that we are now making it invisible. But I guess I was being too
short with what I meant. Here's the full statement:
/*
* task is now visible by other tasks, so updating COMM
* must be protected.
*/
-- Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.