* Re: [PATCH] mm: Introduce new type vm_fault_t
From: Jonathan Corbet @ 2018-07-23 15:42 UTC (permalink / raw)
To: Souptick Joarder
Cc: willy, darrick.wong, gregkh, mszeredi, viro, seanga2, linux-doc,
linux-kernel, ajitn.linux, brajeswar.linux, sabyasachi.linux
In-Reply-To: <20180722130134.GA31321@jordon-HP-15-Notebook-PC>
On Sun, 22 Jul 2018 18:31:34 +0530
Souptick Joarder <jrdr.linux@gmail.com> wrote:
> We have introduce a new return type vm_fault_t for
> fault, page_mkwrite and pfn_mkwrite handlers. Update
> the document for the same
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] mm: Introduce new type vm_fault_t
From: Jonathan Corbet @ 2018-07-23 15:42 UTC (permalink / raw)
To: Souptick Joarder
Cc: willy, darrick.wong, gregkh, mszeredi, viro, seanga2, linux-doc,
linux-kernel, ajitn.linux, brajeswar.linux, sabyasachi.linux
In-Reply-To: <20180722130134.GA31321@jordon-HP-15-Notebook-PC>
On Sun, 22 Jul 2018 18:31:34 +0530
Souptick Joarder <jrdr.linux@gmail.com> wrote:
> We have introduce a new return type vm_fault_t for
> fault, page_mkwrite and pfn_mkwrite handlers. Update
> the document for the same
>
> Signed-off-by: Souptick Joarder <jrdr.linux@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
* [U-Boot] [PATCH v2 5/5] Kconfig: Sort bool, default, select and imply options
From: Alexey Brodkin @ 2018-07-23 15:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <40bfb61f2c4a52a31b26db68dc91caa0f07fda7c.1532354106.git.michal.simek@xilinx.com>
Hi Michal,
On Mon, 2018-07-23 at 15:55 +0200, Michal Simek wrote:
> Another round of sorting Kconfig entries aplhabetically.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> Changes in v2: None
[snip]
> arch/arc/Kconfig | 10 +++++-----
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
^ permalink raw reply
* Re: Regression with crc32c selection?
From: Patrik Lundquist @ 2018-07-23 14:39 UTC (permalink / raw)
To: holger; +Cc: linux-btrfs
In-Reply-To: <ca274e95-538c-0c0e-e184-3542b4524afe@applied-asynchrony.com>
$ uname -a
Linux nas 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux
$ dmesg | grep Btrfs
[ 8.168408] Btrfs loaded, crc32c=crc32c-intel
$ lsmod | grep crc32
crc32_pclmul 16384 0
libcrc32c 16384 1 btrfs
crc32c_generic 16384 0
crc32c_intel 24576 2
$ grep CRC /boot/config-4.17.0-1-amd64
# CONFIG_PCIE_ECRC is not set
# CONFIG_W1_SLAVE_DS2433_CRC is not set
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC4 is not set
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_CRC8=m
On Mon, 23 Jul 2018 at 16:14, Holger Hoffstätte
<holger@applied-asynchrony.com> wrote:
>
> Hi,
>
> While backporting a bunch of fixes to my own 4.16.x tree
> (4.17 had a few too many bugs for my taste) I also ended up merging:
>
> df91f56adce1f: libcrc32c: Add crc32c_impl function
> 9678c54388b6a: btrfs: Remove custom crc32c init code
>
> ..which AFAIK went into 4.17 and seemed harmless enough; after fixing up
> a trivial context conflict it builds, runs, all good..except that btrfs
> (apprently?) no longer uses the preferred crc32c-intel module, but the
> crc32c-generic one instead.
>
> In order to rule out any mistakes on my part I built 4.18.0-rc6 and it
> seems to have the same problem:
>
> Jul 23 15:55:09 ragnarok kernel: raid6: sse2x1 gen() 11267 MB/s
> Jul 23 15:55:09 ragnarok kernel: raid6: sse2x1 xor() 8110 MB/s
> Jul 23 15:55:09 ragnarok kernel: raid6: sse2x2 gen() 13409 MB/s
> Jul 23 15:55:09 ragnarok kernel: raid6: sse2x2 xor() 9137 MB/s
> Jul 23 15:55:09 ragnarok kernel: raid6: sse2x4 gen() 15884 MB/s
> Jul 23 15:55:09 ragnarok kernel: raid6: sse2x4 xor() 10579 MB/s
> Jul 23 15:55:09 ragnarok kernel: raid6: using algorithm sse2x4 gen() 15884 MB/s
> Jul 23 15:55:09 ragnarok kernel: raid6: .... xor() 10579 MB/s, rmw enabled
> Jul 23 15:55:09 ragnarok kernel: raid6: using ssse3x2 recovery algorithm
> Jul 23 15:55:09 ragnarok kernel: xor: automatically using best checksumming function avx
> Jul 23 15:55:09 ragnarok kernel: Btrfs loaded, crc32c=crc32c-generic
>
> I understand that the new crc32c_impl() function changed from
> crypto_tfm_alg_driver_name() to crypto_shash_driver_name() - could this
> be the reason? The module is loaded just fine, but apprently not used:
>
> $lsmod | grep crc32
> crc32_pclmul 16384 0
> crc32c_intel 24576 0
>
> In other words, is this supposed to happen or is my kernel config somehow
> no longer right? It worked before and doesn't look too wrong:
>
> $grep CRC /etc/kernels/kernel-config-x86_64-4.18.0-rc6
> # CONFIG_PCIE_ECRC is not set
> CONFIG_CRYPTO_CRC32C=y
> CONFIG_CRYPTO_CRC32C_INTEL=m
> CONFIG_CRYPTO_CRC32=m
> CONFIG_CRYPTO_CRC32_PCLMUL=m
> # CONFIG_CRYPTO_CRCT10DIF is not set
> CONFIG_CRC_CCITT=m
> CONFIG_CRC16=y
> # CONFIG_CRC_T10DIF is not set
> CONFIG_CRC_ITU_T=y
> CONFIG_CRC32=y
> # CONFIG_CRC32_SELFTEST is not set
> CONFIG_CRC32_SLICEBY8=y
> # CONFIG_CRC32_SLICEBY4 is not set
> # CONFIG_CRC32_SARWATE is not set
> # CONFIG_CRC32_BIT is not set
> # CONFIG_CRC4 is not set
> # CONFIG_CRC7 is not set
> CONFIG_LIBCRC32C=y
> # CONFIG_CRC8 is not set
>
> Ultimately btrfs (and everything else) works, but the process of how
> the kernel selects a crc32c implementation seems rather mysterious to me. :/
>
> Any insights welcome. If it's a regression I can gladly test fixes.
>
> cheers
> Holger
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 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] drivers/memory/Kconfig: Add CONFIG_OF dependency
From: Arnd Bergmann @ 2018-07-23 15:40 UTC (permalink / raw)
To: Boris Brezillon
Cc: Randy Dunlap, Anders Roxell, Miquel Raynal,
Linux Kernel Mailing List, Rob Herring, DTML
In-Reply-To: <20180723114107.664164d2@bbrezillon>
On Mon, Jul 23, 2018 at 11:41 AM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Mon, 23 Jul 2018 11:34:43 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Sun, Jul 22, 2018 at 8:29 AM, Boris Brezillon
>> <boris.brezillon@bootlin.com> wrote:
>> > +Arnd, Rob and the DT ML.
>> >
>> > On Sat, 21 Jul 2018 14:53:47 -0700
>> > Randy Dunlap <rdunlap@infradead.org> wrote:
>> >
>> >> On 07/21/2018 01:00 PM, Anders Roxell wrote:
>> >> > JZ4780_NEMC doesn't depend on OF, and if OF isn't enabled we get this
>> >> > error:
>> >> > 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’; did you mean ‘down_read_nested’?
>> >> > [-Werror=implicit-function-declaration]
>> >> > bank = of_read_number(prop, 1);
>> >> > ^~~~~~~~~~~~~~
>> >> > down_read_nested
>> >
>> > Looks like of.h defines stubs so that people can compile-test without
>> > CONFIG_OF selected. Maybe we should move of_read_number() and
>> > of_read_ulong() out of the #ifdef CONFIG_OF section.
>>
>> That seems fine, though the added dependency seems appropriate
>> here as well. of_read_number() is rarely used, and for the most part in
>> powerpc specific code that is guaranteed to have CONFIG_OF enabled,
>> so it's not that likely to cause many more problems.
>
> Ok, then I'll let Miquel apply Anders' patch to the NAND tree.
>
> Thanks for your feedback.
My randconfig build bot just ran into a second problem with this driver
with CONFIG_GPIOLIB disabled:
drivers/mtd/nand/raw/jz4740_nand.c: In function 'jz_nand_dev_ready':
drivers/mtd/nand/raw/jz4740_nand.c:133:9: error: implicit declaration
of function 'gpiod_get_value_cansleep'; did you mean
'gpio_get_value_cansleep'? [-Werror=implicit-function-declaration]
return gpiod_get_value_cansleep(nand->busy_gpio);
^~~~~~~~~~~~~~~~~~~~~~~~
gpio_get_value_cansleep
drivers/mtd/nand/raw/jz4740_nand.c: In function 'jz_nand_probe':
drivers/mtd/nand/raw/jz4740_nand.c:388:20: error: implicit declaration
of function 'devm_gpiod_get_optional'; did you mean
'devm_gpio_request_one'? [-Werror=implicit-function-declaration]
nand->busy_gpio = devm_gpiod_get_optional(&pdev->dev, "busy", GPIOD_IN);
^~~~~~~~~~~~~~~~~~~~~~~
devm_gpio_request_one
drivers/mtd/nand/raw/jz4740_nand.c:388:64: error: 'GPIOD_IN'
undeclared (first use in this function); did you mean 'GPIOF_IN'?
nand->busy_gpio = devm_gpiod_get_optional(&pdev->dev, "busy", GPIOD_IN);
^~~~~~~~
GPIOF_IN
We could add another dependency here or (my preference) include
linux/gpio/consumer.h to fix that. Do you want a separate patch for
it, or should Anders send a combined patch?
Arnd
^ permalink raw reply
* Re: [PATCH v2 10/12] sched/core: uclamp: use TG's clamps to restrict Task's clamps
From: Patrick Bellasi @ 2018-07-23 15:40 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra, Tejun Heo,
Rafael J . Wysocki, Viresh Kumar, Vincent Guittot, Paul Turner,
Dietmar Eggemann, Morten Rasmussen, Juri Lelli, Todd Kjos,
Joel Fernandes, Steve Muckle
In-Reply-To: <CAJuCfpFnj2g3+ZpR4fP4yqfxs0zd=c-Zehr2XM7m_C+WdL9jNA@mail.gmail.com>
On 21-Jul 20:05, Suren Baghdasaryan wrote:
> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
> <patrick.bellasi@arm.com> wrote:
> > When a task's util_clamp value is configured via sched_setattr(2), this
> > value has to be properly accounted in the corresponding clamp group
> > every time the task is enqueued and dequeued. When cgroups are also in
> > use, per-task clamp values have to be aggregated to those of the CPU's
> > controller's Task Group (TG) in which the task is currently living.
> >
> > Let's update uclamp_cpu_get() to provide aggregation between the task
> > and the TG clamp values. Every time a task is enqueued, it will be
> > accounted in the clamp_group which defines the smaller clamp between the
> > task specific value and its TG value.
>
> So choosing smallest for both UCLAMP_MIN and UCLAMP_MAX means the
> least boosted value and the most clamped value between syscall and TG
> will be used.
Right
> My understanding is that boost means "at least this much" and clamp
> means "at most this much".
Right
> So to satisfy both TG and syscall requirements I think you would
> need to choose the largest value for UCLAMP_MIN and the smallest one
> for UCLAMP_MAX, meaning the most boosted and most clamped range.
> Current implementation choses the least boosted value, so
> effectively one of the UCLAMP_MIN requirements (either from TG or
> from syscall) are being ignored... Could you please clarify why
> this choice is made?
The TG values are always used to specify a _restriction_ on
task-specific values.
Thus, if you look or example at the CPU mask for a task, you can have
a task with affinity to CPUs 0-1, currently running on a cgroup with
cpuset.cpus=0... then the task can run only on CPU 0 (althought its
affinity includes CPU1 too).
Same we do here: if a task has util_min=10, but it's running in a
cgroup with cpu.util_min=0, then it will not be boosted.
IOW, this allows to implement a "nice" policy at task level, where a
task (via syscall) can decide to be less boosted with respect to its
group but never more boosted. The same task can also decide to be more
clamped, but not less clamped then its current group.
[...]
> > @@ -982,18 +989,30 @@ static inline void uclamp_cpu_get_id(struct task_struct *p,
> > int clamp_value;
> > int group_id;
> >
> > - /* No task specific clamp values: nothing to do */
> > group_id = p->uclamp[clamp_id].group_id;
> > + clamp_value = p->uclamp[clamp_id].value;
> > +#ifdef CONFIG_UCLAMP_TASK_GROUP
> > + /* Use TG's clamp value to limit task specific values */
> > + if (group_id == UCLAMP_NONE ||
> > + clamp_value >= task_group(p)->uclamp[clamp_id].value) {
>
> Not a big deal but do you need to override if (clamp_value ==
> task_group(p)->uclamp[clamp_id].value)? Maybe:
> - clamp_value >= task_group(p)->uclamp[clamp_id].value) {
> + clamp_value > task_group(p)->uclamp[clamp_id].value) {
Good point, yes... the override is not really changing anything here.
Will fix this!
> > + clamp_value = task_group(p)->uclamp[clamp_id].value;
> > + group_id = task_group(p)->uclamp[clamp_id].group_id;
> > + }
> > +#else
> > + /* No task specific clamp values: nothing to do */
> > if (group_id == UCLAMP_NONE)
> > return;
> > +#endif
> >
> > /* Reference count the task into its current group_id */
> > uc_grp = &rq->uclamp.group[clamp_id][0];
> > uc_grp[group_id].tasks += 1;
> >
> > + /* Track the effective clamp group */
> > + p->uclamp_group_id[clamp_id] = group_id;
> > +
> > /* Force clamp update on idle exit */
> > uc_cpu = &rq->uclamp;
> > - clamp_value = p->uclamp[clamp_id].value;
> > if (unlikely(uc_cpu->flags & UCLAMP_FLAG_IDLE)) {
> > if (clamp_id == UCLAMP_MAX)
> > uc_cpu->flags &= ~UCLAMP_FLAG_IDLE;
[...]
--
#include <best/regards.h>
Patrick Bellasi
^ permalink raw reply
* [MODERATED] Re: [RFC PATCH 4/6] kvm: handle host mode irqs 4
From: Andi Kleen @ 2018-07-23 15:40 UTC (permalink / raw)
To: speck
In-Reply-To: <6815cf025aa41954f911a1e76c2415035307b00f.1532339695.git.nstange@suse.de>
> +.macro TRACK_KERNEL_MODE_IRQ
> +#ifdef CONFIG_X86_TRACK_KERNEL_MODE_IRQS
> + /*
> + * Increment the kernel mode irq generation count even if
> + * coming from userspace -- nobody will care.
> + */
> + incl PER_CPU_VAR(kernel_mode_irq_gen)
> +#endif
> +.endm
You can put it into irq_enter/exit, no need to mess with assembler code.
-Andi
^ permalink raw reply
* Re: [PATCH xf86-video-ati] Hardcode "non-desktop" RandR property name
From: Alex Deucher @ 2018-07-23 15:40 UTC (permalink / raw)
To: Michel Dänzer; +Cc: amd-gfx list
In-Reply-To: <20180723090423.2336-1-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
On Mon, Jul 23, 2018 at 5:04 AM, Michel Dänzer <michel@daenzer.net> wrote:
> From: Michel Dänzer <michel.daenzer@amd.com>
>
> It's a bit silly to require current randrproto just for this definition,
> which can't really change anyway.
>
> Suggested-by: Qiang Yu <qiang.yu@amd.com>
> (Ported from amdgpu commit ae8e02c6fc4ef5d5340b8cd4739e66b19b9e3386)
>
> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> configure.ac | 2 +-
> src/drmmode_display.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 15c7b2128..bea205c34 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -64,7 +64,7 @@ AC_ARG_WITH(xorg-module-dir,
> [moduledir="$libdir/xorg/modules"])
>
> # Store the list of server defined optional extensions in REQUIRED_MODULES
> -XORG_DRIVER_CHECK_EXT(RANDR, [randrproto >= 1.6.0])
> +XORG_DRIVER_CHECK_EXT(RANDR, randrproto)
> XORG_DRIVER_CHECK_EXT(RENDER, renderproto)
> XORG_DRIVER_CHECK_EXT(XV, videoproto)
> XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index 000c7fc62..ff098975f 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -2012,7 +2012,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr mode_r
>
> #if XF86_CRTC_VERSION >= 8
> i = koutput_get_prop_idx(pRADEONEnt->fd, koutput, DRM_MODE_PROP_RANGE,
> - RR_PROPERTY_NON_DESKTOP);
> + "non-desktop");
> if (i >= 0)
> nonDesktop = koutput->prop_values[i] != 0;
> #endif
> --
> 2.18.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [Qemu-arm] [Qemu-devel] [PATCH] target/arm: Escalate to correct HardFault when AIRCR.BFHFNMINS is set
From: Richard Henderson @ 2018-07-23 15:39 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel; +Cc: patches
In-Reply-To: <20180723123457.2038-1-peter.maydell@linaro.org>
On 07/23/2018 05:34 AM, Peter Maydell wrote:
> When we escalate a v8M exception to HardFault, if AIRCR.BFHFNMINNS is
> set then we need to decide whether it should become a secure HardFault
> or a nonsecure HardFault. We should always escalate to the same
> target security state as the original exception. The current code
> tries to test this using the 'secure' bool, which is not right because
> that flag indicates whether the target security state only for
> banked exceptions; the effect was that we were incorrectly escalating
> always-secure exceptions like SecureFault to a nonsecure HardFault.
>
> Fix this by defining, logging and using a new 'targets_secure' bool
> which tracks the condition we actually want.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> hw/intc/armv7m_nvic.c | 8 ++++++--
> hw/intc/trace-events | 2 +-
> 2 files changed, 7 insertions(+), 3 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] target/arm: Escalate to correct HardFault when AIRCR.BFHFNMINS is set
From: Richard Henderson @ 2018-07-23 15:39 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel; +Cc: patches
In-Reply-To: <20180723123457.2038-1-peter.maydell@linaro.org>
On 07/23/2018 05:34 AM, Peter Maydell wrote:
> When we escalate a v8M exception to HardFault, if AIRCR.BFHFNMINNS is
> set then we need to decide whether it should become a secure HardFault
> or a nonsecure HardFault. We should always escalate to the same
> target security state as the original exception. The current code
> tries to test this using the 'secure' bool, which is not right because
> that flag indicates whether the target security state only for
> banked exceptions; the effect was that we were incorrectly escalating
> always-secure exceptions like SecureFault to a nonsecure HardFault.
>
> Fix this by defining, logging and using a new 'targets_secure' bool
> which tracks the condition we actually want.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> hw/intc/armv7m_nvic.c | 8 ++++++--
> hw/intc/trace-events | 2 +-
> 2 files changed, 7 insertions(+), 3 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [PATCH] mtd: nand: fix spelling in driver api documentation
From: Jonathan Corbet @ 2018-07-23 15:39 UTC (permalink / raw)
To: Marcel Ziswiler
Cc: linux-mtd, Marcel Ziswiler, Gregory CLEMENT, H Hartley Sweeten,
linux-doc, linux-kernel, Krzysztof Kozlowski, Boris Brezillon,
Vladimir Zapolskiy
In-Reply-To: <20180720075334.24254-1-marcel@ziswiler.com>
On Fri, 20 Jul 2018 09:53:33 +0200
Marcel Ziswiler <marcel@ziswiler.com> wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> This fixes some spelling mistakes.
So I hate to complain about a documentation improvement, but...
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> ---
>
> Documentation/driver-api/mtdnand.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/driver-api/mtdnand.rst b/Documentation/driver-api/mtdnand.rst
> index dcd63599f700..c55a6034c397 100644
> --- a/Documentation/driver-api/mtdnand.rst
> +++ b/Documentation/driver-api/mtdnand.rst
> @@ -374,7 +374,7 @@ The nand driver supports three different types of hardware ECC.
>
> - NAND_ECC_HW8_512
>
> - Hardware ECC generator providing 6 bytes ECC per 512 byte.
> + Hardware ECC generator providing 8 bytes ECC per 512 byte.
That's not a spelling mistake, that's a factual change. I'll apply the
patch since it appears to be correct, but will be tweaking the changelog.
Thanks,
jon
^ permalink raw reply
* [PATCH v2] UBI: Add volume read and write statistics
From: Per Forlin @ 2018-07-23 15:39 UTC (permalink / raw)
To: linux-mtd; +Cc: Artem Bityutskiy, Richard Weinberger, derosier, Per Forlin
Simple read and write statistics.
* Number of reads
* Number of writes
* Bytes read
* Bytes written
This is useful to find out how the storage is being utilized.
For block devices this already exists here:
/sys/class/block/<device>/stat
For UBI it now exists here:
/sys/class/ubi/<volume>/stat
Example:
/sys/class/ubi/ubi0_21/stat
864 0 3106756 0 1057 0 2144256 0 0 0 0
The output format is same as for block devices
except that not all metrics are supported yet.
Unsupported values are set to 0.
---
Changelog:
v2
* Question: Translate bytes to sectors? iostats format expects sector unit.
* Align with iostats format
* Only count successful reads and writes
drivers/mtd/ubi/eba.c | 11 ++++++++++-
drivers/mtd/ubi/ubi.h | 19 +++++++++++++++++++
drivers/mtd/ubi/vmt.c | 8 ++++++++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
index b98481b..c9a88b2 100644
--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -731,6 +731,11 @@ int ubi_eba_read_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum,
}
}
+ if (!err) {
+ vol->stat.rcount++;
+ vol->stat.rbytes += len;
+ }
+
if (scrub)
err = ubi_wl_scrub_peb(ubi, pnum);
@@ -1091,8 +1096,12 @@ int ubi_eba_write_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum,
ubi_free_vid_buf(vidb);
out:
- if (err)
+ if (err) {
ubi_ro_mode(ubi);
+ } else {
+ vol->stat.wcount++;
+ vol->stat.wbytes += len;
+ }
leb_write_unlock(ubi, vol_id, lnum);
diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
index f5ba97c..0cb00f0 100644
--- a/drivers/mtd/ubi/ubi.h
+++ b/drivers/mtd/ubi/ubi.h
@@ -293,6 +293,23 @@ struct ubi_eba_leb_desc {
};
/**
+ * struct ubi_volume_stat - Volume statistics
+ * @rbytes: the number of bytes read
+ * @wbytes: the number of bytes written
+ * @rcount: the number of read requests
+ * @wcount: the number of write requests
+ *
+ * This structure contains read and write statistics.
+ *
+ */
+struct ubi_volume_stat {
+ u64 rbytes;
+ u64 wbytes;
+ u32 rcount;
+ u32 wcount;
+};
+
+/**
* struct ubi_volume - UBI volume description data structure.
* @dev: device object to make use of the the Linux device model
* @cdev: character device object to create character device
@@ -384,6 +401,8 @@ struct ubi_volume {
#ifdef CONFIG_MTD_UBI_FASTMAP
unsigned long *checkmap;
#endif
+
+ struct ubi_volume_stat stat;
};
/**
diff --git a/drivers/mtd/ubi/vmt.c b/drivers/mtd/ubi/vmt.c
index 0be5167..69b5375 100644
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -51,6 +51,8 @@ static struct device_attribute attr_vol_data_bytes =
__ATTR(data_bytes, S_IRUGO, vol_attribute_show, NULL);
static struct device_attribute attr_vol_upd_marker =
__ATTR(upd_marker, S_IRUGO, vol_attribute_show, NULL);
+static struct device_attribute attr_vol_stat =
+ __ATTR(stat, S_IRUGO, vol_attribute_show, NULL);
/*
* "Show" method for files in '/<sysfs>/class/ubi/ubiX_Y/'.
@@ -107,6 +109,11 @@ static ssize_t vol_attribute_show(struct device *dev,
ret = sprintf(buf, "%lld\n", vol->used_bytes);
else if (attr == &attr_vol_upd_marker)
ret = sprintf(buf, "%d\n", vol->upd_marker);
+ else if (attr == &attr_vol_stat)
+ /* Format conforming to Documentation/iostats.txt */
+ ret = sprintf(buf, "%u 0 %llu 0 %u 0 %llu 0 0 0 0\n",
+ vol->stat.rcount, vol->stat.rbytes,
+ vol->stat.wcount, vol->stat.wbytes);
else
/* This must be a bug */
ret = -EINVAL;
@@ -129,6 +136,7 @@ static struct attribute *volume_dev_attrs[] = {
&attr_vol_usable_eb_size.attr,
&attr_vol_data_bytes.attr,
&attr_vol_upd_marker.attr,
+ &attr_vol_stat.attr,
NULL
};
ATTRIBUTE_GROUPS(volume_dev);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] mtd: nand: fix spelling in driver api documentation
From: Jonathan Corbet @ 2018-07-23 15:39 UTC (permalink / raw)
To: Marcel Ziswiler
Cc: linux-mtd, Marcel Ziswiler, Gregory CLEMENT, H Hartley Sweeten,
linux-doc, linux-kernel, Krzysztof Kozlowski, Boris Brezillon,
Vladimir Zapolskiy
In-Reply-To: <20180720075334.24254-1-marcel@ziswiler.com>
On Fri, 20 Jul 2018 09:53:33 +0200
Marcel Ziswiler <marcel@ziswiler.com> wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> This fixes some spelling mistakes.
So I hate to complain about a documentation improvement, but...
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> ---
>
> Documentation/driver-api/mtdnand.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/driver-api/mtdnand.rst b/Documentation/driver-api/mtdnand.rst
> index dcd63599f700..c55a6034c397 100644
> --- a/Documentation/driver-api/mtdnand.rst
> +++ b/Documentation/driver-api/mtdnand.rst
> @@ -374,7 +374,7 @@ The nand driver supports three different types of hardware ECC.
>
> - NAND_ECC_HW8_512
>
> - Hardware ECC generator providing 6 bytes ECC per 512 byte.
> + Hardware ECC generator providing 8 bytes ECC per 512 byte.
That's not a spelling mistake, that's a factual change. I'll apply the
patch since it appears to be correct, but will be tweaking the changelog.
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
* [Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
From: bugzilla-daemon @ 2018-07-23 15:39 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-107296-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 319 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=107296
--- Comment #2 from Paul Menzel <pmenzel+bugs.freedesktop@molgen.mpg.de> ---
Adding print statements, it turns out, the second function
`verify_clock_values(&fclks)` returns *false*.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1300 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] staging: gasket: use vzalloc instead of vmalloc/memset
From: Greg KH @ 2018-07-23 15:38 UTC (permalink / raw)
To: Ivan Bornyakov; +Cc: devel, jnjoseph, linux-kernel, rspringer
In-Reply-To: <20180723150538.3520-1-brnkv.i1@gmail.com>
On Mon, Jul 23, 2018 at 06:05:38PM +0300, Ivan Bornyakov wrote:
> Signed-off-by: Ivan Bornyakov <brnkv.i1@gmail.com>
> ---
> drivers/staging/gasket/gasket_page_table.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
I can not take patches without any changelog text at all, sorry.
greg k-h
^ permalink raw reply
* [PATCH net-next 6/6] virtio_net: Add kick stats
From: Toshiaki Makita @ 2018-07-23 14:36 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: Toshiaki Makita, netdev, virtualization
In-Reply-To: <20180723143609.2242-1-toshiaki.makita1@gmail.com>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
So we can infer the number of VM-Exits.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/virtio_net.c | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cb4ef331567c..1880c86e84b4 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -84,6 +84,7 @@ struct virtnet_sq_stats {
u64 bytes;
u64 xdp_tx;
u64 xdp_tx_drops;
+ u64 kicks;
};
struct virtnet_rq_stat_items {
@@ -94,6 +95,7 @@ struct virtnet_rq_stat_items {
u64 xdp_tx;
u64 xdp_redirects;
u64 xdp_drops;
+ u64 kicks;
};
struct virtnet_rq_stats {
@@ -117,6 +119,7 @@ static const struct virtnet_stat_desc virtnet_sq_stats_desc[] = {
{ "bytes", VIRTNET_SQ_STAT(bytes) },
{ "xdp_tx", VIRTNET_SQ_STAT(xdp_tx) },
{ "xdp_tx_drops", VIRTNET_SQ_STAT(xdp_tx_drops) },
+ { "kicks", VIRTNET_SQ_STAT(kicks) },
};
static const struct virtnet_stat_desc virtnet_rq_stats_desc[] = {
@@ -127,6 +130,7 @@ static const struct virtnet_stat_desc virtnet_rq_stats_desc[] = {
{ "xdp_tx", VIRTNET_RQ_STAT(xdp_tx) },
{ "xdp_redirects", VIRTNET_RQ_STAT(xdp_redirects) },
{ "xdp_drops", VIRTNET_RQ_STAT(xdp_drops) },
+ { "kicks", VIRTNET_RQ_STAT(kicks) },
};
#define VIRTNET_SQ_STATS_LEN ARRAY_SIZE(virtnet_sq_stats_desc)
@@ -507,6 +511,7 @@ static int virtnet_xdp_xmit(struct net_device *dev,
struct send_queue *sq;
unsigned int len;
int drops = 0;
+ int kicks = 0;
int ret, err;
int i;
@@ -543,12 +548,15 @@ static int virtnet_xdp_xmit(struct net_device *dev,
}
ret = n - drops;
- if (flags & XDP_XMIT_FLUSH)
- virtqueue_kick(sq->vq);
+ if (flags & XDP_XMIT_FLUSH) {
+ if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq))
+ kicks = 1;
+ }
out:
u64_stats_update_begin(&sq->stats.syncp);
sq->stats.xdp_tx += n;
sq->stats.xdp_tx_drops += drops;
+ sq->stats.kicks += kicks;
u64_stats_update_end(&sq->stats.syncp);
return ret;
@@ -1226,7 +1234,12 @@ static bool try_fill_recv(struct virtnet_info *vi, struct receive_queue *rq,
if (err)
break;
} while (rq->vq->num_free);
- virtqueue_kick(rq->vq);
+ if (virtqueue_kick_prepare(rq->vq) && virtqueue_notify(rq->vq)) {
+ u64_stats_update_begin(&rq->stats.syncp);
+ rq->stats.items.kicks++;
+ u64_stats_update_end(&rq->stats.syncp);
+ }
+
return !oom;
}
@@ -1416,7 +1429,11 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
if (xdp_xmit & VIRTIO_XDP_TX) {
sq = virtnet_xdp_sq(vi);
- virtqueue_kick(sq->vq);
+ if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq)) {
+ u64_stats_update_begin(&sq->stats.syncp);
+ sq->stats.kicks++;
+ u64_stats_update_end(&sq->stats.syncp);
+ }
}
return received;
@@ -1578,8 +1595,13 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
}
}
- if (kick || netif_xmit_stopped(txq))
- virtqueue_kick(sq->vq);
+ if (kick || netif_xmit_stopped(txq)) {
+ if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq)) {
+ u64_stats_update_begin(&sq->stats.syncp);
+ sq->stats.kicks++;
+ u64_stats_update_end(&sq->stats.syncp);
+ }
+ }
return NETDEV_TX_OK;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 5/6] virtio_net: Add XDP related stats
From: Toshiaki Makita @ 2018-07-23 14:36 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: Toshiaki Makita, netdev, virtualization
In-Reply-To: <20180723143609.2242-1-toshiaki.makita1@gmail.com>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Add counters below:
* Tx
- xdp_tx: frames sent by ndo_xdp_xmit or XDP_TX.
- xdp_tx_drops: dropped frames out of xdp_tx ones.
* Rx
- xdp_packets: frames went through xdp program.
- xdp_tx: XDP_TX frames.
- xdp_redirects: XDP_REDIRECT frames.
- xdp_drops: any dropped frames out of xdp_packets ones.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/virtio_net.c | 71 ++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 59 insertions(+), 12 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index eca9b13b859e..cb4ef331567c 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -82,12 +82,18 @@ struct virtnet_sq_stats {
struct u64_stats_sync syncp;
u64 packets;
u64 bytes;
+ u64 xdp_tx;
+ u64 xdp_tx_drops;
};
struct virtnet_rq_stat_items {
u64 packets;
u64 bytes;
u64 drops;
+ u64 xdp_packets;
+ u64 xdp_tx;
+ u64 xdp_redirects;
+ u64 xdp_drops;
};
struct virtnet_rq_stats {
@@ -97,20 +103,30 @@ struct virtnet_rq_stats {
struct virtnet_rx_stats {
struct virtnet_rq_stat_items rx;
+ struct {
+ unsigned int xdp_tx;
+ unsigned int xdp_tx_drops;
+ } tx;
};
#define VIRTNET_SQ_STAT(m) offsetof(struct virtnet_sq_stats, m)
#define VIRTNET_RQ_STAT(m) offsetof(struct virtnet_rq_stat_items, m)
static const struct virtnet_stat_desc virtnet_sq_stats_desc[] = {
- { "packets", VIRTNET_SQ_STAT(packets) },
- { "bytes", VIRTNET_SQ_STAT(bytes) },
+ { "packets", VIRTNET_SQ_STAT(packets) },
+ { "bytes", VIRTNET_SQ_STAT(bytes) },
+ { "xdp_tx", VIRTNET_SQ_STAT(xdp_tx) },
+ { "xdp_tx_drops", VIRTNET_SQ_STAT(xdp_tx_drops) },
};
static const struct virtnet_stat_desc virtnet_rq_stats_desc[] = {
- { "packets", VIRTNET_RQ_STAT(packets) },
- { "bytes", VIRTNET_RQ_STAT(bytes) },
- { "drops", VIRTNET_RQ_STAT(drops) },
+ { "packets", VIRTNET_RQ_STAT(packets) },
+ { "bytes", VIRTNET_RQ_STAT(bytes) },
+ { "drops", VIRTNET_RQ_STAT(drops) },
+ { "xdp_packets", VIRTNET_RQ_STAT(xdp_packets) },
+ { "xdp_tx", VIRTNET_RQ_STAT(xdp_tx) },
+ { "xdp_redirects", VIRTNET_RQ_STAT(xdp_redirects) },
+ { "xdp_drops", VIRTNET_RQ_STAT(xdp_drops) },
};
#define VIRTNET_SQ_STATS_LEN ARRAY_SIZE(virtnet_sq_stats_desc)
@@ -491,20 +507,26 @@ static int virtnet_xdp_xmit(struct net_device *dev,
struct send_queue *sq;
unsigned int len;
int drops = 0;
- int err;
+ int ret, err;
int i;
- if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
- return -EINVAL;
-
sq = virtnet_xdp_sq(vi);
+ if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK)) {
+ ret = -EINVAL;
+ drops = n;
+ goto out;
+ }
+
/* Only allow ndo_xdp_xmit if XDP is loaded on dev, as this
* indicate XDP resources have been successfully allocated.
*/
xdp_prog = rcu_dereference(rq->xdp_prog);
- if (!xdp_prog)
- return -ENXIO;
+ if (!xdp_prog) {
+ ret = -ENXIO;
+ drops = n;
+ goto out;
+ }
/* Free up any pending old buffers before queueing new ones. */
while ((xdpf_sent = virtqueue_get_buf(sq->vq, &len)) != NULL)
@@ -519,11 +541,17 @@ static int virtnet_xdp_xmit(struct net_device *dev,
drops++;
}
}
+ ret = n - drops;
if (flags & XDP_XMIT_FLUSH)
virtqueue_kick(sq->vq);
+out:
+ u64_stats_update_begin(&sq->stats.syncp);
+ sq->stats.xdp_tx += n;
+ sq->stats.xdp_tx_drops += drops;
+ u64_stats_update_end(&sq->stats.syncp);
- return n - drops;
+ return ret;
}
static unsigned int virtnet_get_headroom(struct virtnet_info *vi)
@@ -658,6 +686,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
xdp.rxq = &rq->xdp_rxq;
orig_data = xdp.data;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
+ stats->rx.xdp_packets++;
switch (act) {
case XDP_PASS:
@@ -666,11 +695,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
len = xdp.data_end - xdp.data;
break;
case XDP_TX:
+ stats->rx.xdp_tx++;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
+ stats->tx.xdp_tx++;
err = __virtnet_xdp_tx_xmit(vi, xdpf);
if (unlikely(err)) {
+ stats->tx.xdp_tx_drops++;
trace_xdp_exception(vi->dev, xdp_prog, act);
goto err_xdp;
}
@@ -678,6 +710,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
rcu_read_unlock();
goto xdp_xmit;
case XDP_REDIRECT:
+ stats->rx.xdp_redirects++;
err = xdp_do_redirect(dev, &xdp, xdp_prog);
if (err)
goto err_xdp;
@@ -711,6 +744,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
err_xdp:
rcu_read_unlock();
+ stats->rx.xdp_drops++;
stats->rx.drops++;
put_page(page);
xdp_xmit:
@@ -808,6 +842,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
xdp.rxq = &rq->xdp_rxq;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
+ stats->rx.xdp_packets++;
switch (act) {
case XDP_PASS:
@@ -832,11 +867,14 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
}
break;
case XDP_TX:
+ stats->rx.xdp_tx++;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
+ stats->tx.xdp_tx++;
err = __virtnet_xdp_tx_xmit(vi, xdpf);
if (unlikely(err)) {
+ stats->tx.xdp_tx_drops++;
trace_xdp_exception(vi->dev, xdp_prog, act);
if (unlikely(xdp_page != page))
put_page(xdp_page);
@@ -848,6 +886,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
rcu_read_unlock();
goto xdp_xmit;
case XDP_REDIRECT:
+ stats->rx.xdp_redirects++;
err = xdp_do_redirect(dev, &xdp, xdp_prog);
if (err) {
if (unlikely(xdp_page != page))
@@ -943,6 +982,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
err_xdp:
rcu_read_unlock();
+ stats->rx.xdp_drops++;
err_skb:
put_page(page);
while (num_buf-- > 1) {
@@ -1262,6 +1302,7 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
{
struct virtnet_info *vi = rq->vq->vdev->priv;
struct virtnet_rx_stats stats = {};
+ struct send_queue *sq;
unsigned int len;
void *buf;
int i;
@@ -1297,6 +1338,12 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
}
u64_stats_update_end(&rq->stats.syncp);
+ sq = virtnet_xdp_sq(vi);
+ u64_stats_update_begin(&sq->stats.syncp);
+ sq->stats.xdp_tx += stats.tx.xdp_tx;
+ sq->stats.xdp_tx_drops += stats.tx.xdp_tx_drops;
+ u64_stats_update_end(&sq->stats.syncp);
+
return stats.rx.packets;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 4/6] virtio_net: Factor out the logic to determine xdp sq
From: Toshiaki Makita @ 2018-07-23 14:36 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: Toshiaki Makita, netdev, virtualization
In-Reply-To: <20180723143609.2242-1-toshiaki.makita1@gmail.com>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Make sure to use the same logic in all places to determine xdp sq. This
is useful for xdp counters which the following commit will introduce as
well.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/virtio_net.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7a47ce750a43..eca9b13b859e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -457,16 +457,22 @@ static int __virtnet_xdp_xmit_one(struct virtnet_info *vi,
return 0;
}
+static struct send_queue *virtnet_xdp_sq(struct virtnet_info *vi)
+{
+ unsigned int qp;
+
+ qp = vi->curr_queue_pairs - vi->xdp_queue_pairs + smp_processor_id();
+ return &vi->sq[qp];
+}
+
static int __virtnet_xdp_tx_xmit(struct virtnet_info *vi,
struct xdp_frame *xdpf)
{
struct xdp_frame *xdpf_sent;
struct send_queue *sq;
unsigned int len;
- unsigned int qp;
- qp = vi->curr_queue_pairs - vi->xdp_queue_pairs + smp_processor_id();
- sq = &vi->sq[qp];
+ sq = virtnet_xdp_sq(vi);
/* Free up any pending old buffers before queueing new ones. */
while ((xdpf_sent = virtqueue_get_buf(sq->vq, &len)) != NULL)
@@ -484,7 +490,6 @@ static int virtnet_xdp_xmit(struct net_device *dev,
struct bpf_prog *xdp_prog;
struct send_queue *sq;
unsigned int len;
- unsigned int qp;
int drops = 0;
int err;
int i;
@@ -492,8 +497,7 @@ static int virtnet_xdp_xmit(struct net_device *dev,
if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
return -EINVAL;
- qp = vi->curr_queue_pairs - vi->xdp_queue_pairs + smp_processor_id();
- sq = &vi->sq[qp];
+ sq = virtnet_xdp_sq(vi);
/* Only allow ndo_xdp_xmit if XDP is loaded on dev, as this
* indicate XDP resources have been successfully allocated.
@@ -1349,7 +1353,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
container_of(napi, struct receive_queue, napi);
struct virtnet_info *vi = rq->vq->vdev->priv;
struct send_queue *sq;
- unsigned int received, qp;
+ unsigned int received;
unsigned int xdp_xmit = 0;
virtnet_poll_cleantx(rq);
@@ -1364,9 +1368,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
xdp_do_flush_map();
if (xdp_xmit & VIRTIO_XDP_TX) {
- qp = vi->curr_queue_pairs - vi->xdp_queue_pairs +
- smp_processor_id();
- sq = &vi->sq[qp];
+ sq = virtnet_xdp_sq(vi);
virtqueue_kick(sq->vq);
}
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 3/6] virtio_net: Make drop counter per-queue
From: Toshiaki Makita @ 2018-07-23 14:36 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: Toshiaki Makita, netdev, virtualization
In-Reply-To: <20180723143609.2242-1-toshiaki.makita1@gmail.com>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Since when XDP was introduced, drop counter has been able to be updated
much more frequently than before, as XDP_DROP increments the counter.
Thus for performance analysis per-queue drop counter would be useful.
Also this avoids cache contention and race on updating the counter. It
is currently racy because napi handlers read-modify-write it without any
locks.
There are more counters in dev->stats that are racy, but I left them
per-device, because they are rarely updated and does not worth being
per-queue counters IMHO. To fix them we need atomic ops or some kind of
locks.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/virtio_net.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d03bfc4fce8e..7a47ce750a43 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -87,6 +87,7 @@ struct virtnet_sq_stats {
struct virtnet_rq_stat_items {
u64 packets;
u64 bytes;
+ u64 drops;
};
struct virtnet_rq_stats {
@@ -109,6 +110,7 @@ static const struct virtnet_stat_desc virtnet_sq_stats_desc[] = {
static const struct virtnet_stat_desc virtnet_rq_stats_desc[] = {
{ "packets", VIRTNET_RQ_STAT(packets) },
{ "bytes", VIRTNET_RQ_STAT(bytes) },
+ { "drops", VIRTNET_RQ_STAT(drops) },
};
#define VIRTNET_SQ_STATS_LEN ARRAY_SIZE(virtnet_sq_stats_desc)
@@ -705,7 +707,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
err_xdp:
rcu_read_unlock();
- dev->stats.rx_dropped++;
+ stats->rx.drops++;
put_page(page);
xdp_xmit:
return NULL;
@@ -728,7 +730,7 @@ static struct sk_buff *receive_big(struct net_device *dev,
return skb;
err:
- dev->stats.rx_dropped++;
+ stats->rx.drops++;
give_pages(rq, page);
return NULL;
}
@@ -952,7 +954,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
put_page(page);
}
err_buf:
- dev->stats.rx_dropped++;
+ stats->rx.drops++;
dev_kfree_skb(head_skb);
xdp_xmit:
return NULL;
@@ -1632,7 +1634,7 @@ static void virtnet_stats(struct net_device *dev,
int i;
for (i = 0; i < vi->max_queue_pairs; i++) {
- u64 tpackets, tbytes, rpackets, rbytes;
+ u64 tpackets, tbytes, rpackets, rbytes, rdrops;
struct receive_queue *rq = &vi->rq[i];
struct send_queue *sq = &vi->sq[i];
@@ -1646,17 +1648,18 @@ static void virtnet_stats(struct net_device *dev,
start = u64_stats_fetch_begin_irq(&rq->stats.syncp);
rpackets = rq->stats.items.packets;
rbytes = rq->stats.items.bytes;
+ rdrops = rq->stats.items.drops;
} while (u64_stats_fetch_retry_irq(&rq->stats.syncp, start));
tot->rx_packets += rpackets;
tot->tx_packets += tpackets;
tot->rx_bytes += rbytes;
tot->tx_bytes += tbytes;
+ tot->rx_dropped += rdrops;
}
tot->tx_dropped = dev->stats.tx_dropped;
tot->tx_fifo_errors = dev->stats.tx_fifo_errors;
- tot->rx_dropped = dev->stats.rx_dropped;
tot->rx_length_errors = dev->stats.rx_length_errors;
tot->rx_frame_errors = dev->stats.rx_frame_errors;
}
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 2/6] virtio_net: Use temporary storage for accounting rx stats
From: Toshiaki Makita @ 2018-07-23 14:36 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: Toshiaki Makita, netdev, virtualization
In-Reply-To: <20180723143609.2242-1-toshiaki.makita1@gmail.com>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
The purpose is to keep receive_buf arguments simple when more per-queue
counter items are added later.
Also XDP_TX related sq counters will be updated in the following changes
so create a container struct virtnet_rx_stats which will includes both
rq and sq statistics. For now it only covers rq stats.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/virtio_net.c | 72 +++++++++++++++++++++++++++++-------------------
1 file changed, 44 insertions(+), 28 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index abbd3bc83b62..d03bfc4fce8e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -84,14 +84,22 @@ struct virtnet_sq_stats {
u64 bytes;
};
-struct virtnet_rq_stats {
- struct u64_stats_sync syncp;
+struct virtnet_rq_stat_items {
u64 packets;
u64 bytes;
};
+struct virtnet_rq_stats {
+ struct u64_stats_sync syncp;
+ struct virtnet_rq_stat_items items;
+};
+
+struct virtnet_rx_stats {
+ struct virtnet_rq_stat_items rx;
+};
+
#define VIRTNET_SQ_STAT(m) offsetof(struct virtnet_sq_stats, m)
-#define VIRTNET_RQ_STAT(m) offsetof(struct virtnet_rq_stats, m)
+#define VIRTNET_RQ_STAT(m) offsetof(struct virtnet_rq_stat_items, m)
static const struct virtnet_stat_desc virtnet_sq_stats_desc[] = {
{ "packets", VIRTNET_SQ_STAT(packets) },
@@ -587,7 +595,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
void *buf, void *ctx,
unsigned int len,
unsigned int *xdp_xmit,
- unsigned int *rbytes)
+ struct virtnet_rx_stats *stats)
{
struct sk_buff *skb;
struct bpf_prog *xdp_prog;
@@ -602,7 +610,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
int err;
len -= vi->hdr_len;
- *rbytes += len;
+ stats->rx.bytes += len;
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -708,12 +716,12 @@ static struct sk_buff *receive_big(struct net_device *dev,
struct receive_queue *rq,
void *buf,
unsigned int len,
- unsigned int *rbytes)
+ struct virtnet_rx_stats *stats)
{
struct page *page = buf;
struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
- *rbytes += len - vi->hdr_len;
+ stats->rx.bytes += len - vi->hdr_len;
if (unlikely(!skb))
goto err;
@@ -732,7 +740,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
void *ctx,
unsigned int len,
unsigned int *xdp_xmit,
- unsigned int *rbytes)
+ struct virtnet_rx_stats *stats)
{
struct virtio_net_hdr_mrg_rxbuf *hdr = buf;
u16 num_buf = virtio16_to_cpu(vi->vdev, hdr->num_buffers);
@@ -745,7 +753,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
int err;
head_skb = NULL;
- *rbytes += len - vi->hdr_len;
+ stats->rx.bytes += len - vi->hdr_len;
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -883,7 +891,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
goto err_buf;
}
- *rbytes += len;
+ stats->rx.bytes += len;
page = virt_to_head_page(buf);
truesize = mergeable_ctx_to_truesize(ctx);
@@ -939,7 +947,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
dev->stats.rx_length_errors++;
break;
}
- *rbytes += len;
+ stats->rx.bytes += len;
page = virt_to_head_page(buf);
put_page(page);
}
@@ -952,7 +960,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
void *buf, unsigned int len, void **ctx,
- unsigned int *xdp_xmit, unsigned int *rbytes)
+ unsigned int *xdp_xmit,
+ struct virtnet_rx_stats *stats)
{
struct net_device *dev = vi->dev;
struct sk_buff *skb;
@@ -973,11 +982,11 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
if (vi->mergeable_rx_bufs)
skb = receive_mergeable(dev, vi, rq, buf, ctx, len, xdp_xmit,
- rbytes);
+ stats);
else if (vi->big_packets)
- skb = receive_big(dev, vi, rq, buf, len, rbytes);
+ skb = receive_big(dev, vi, rq, buf, len, stats);
else
- skb = receive_small(dev, vi, rq, buf, ctx, len, xdp_xmit, rbytes);
+ skb = receive_small(dev, vi, rq, buf, ctx, len, xdp_xmit, stats);
if (unlikely(!skb))
return;
@@ -1246,22 +1255,24 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
unsigned int *xdp_xmit)
{
struct virtnet_info *vi = rq->vq->vdev->priv;
- unsigned int len, received = 0, bytes = 0;
+ struct virtnet_rx_stats stats = {};
+ unsigned int len;
void *buf;
+ int i;
if (!vi->big_packets || vi->mergeable_rx_bufs) {
void *ctx;
- while (received < budget &&
+ while (stats.rx.packets < budget &&
(buf = virtqueue_get_buf_ctx(rq->vq, &len, &ctx))) {
- receive_buf(vi, rq, buf, len, ctx, xdp_xmit, &bytes);
- received++;
+ receive_buf(vi, rq, buf, len, ctx, xdp_xmit, &stats);
+ stats.rx.packets++;
}
} else {
- while (received < budget &&
+ while (stats.rx.packets < budget &&
(buf = virtqueue_get_buf(rq->vq, &len)) != NULL) {
- receive_buf(vi, rq, buf, len, NULL, xdp_xmit, &bytes);
- received++;
+ receive_buf(vi, rq, buf, len, NULL, xdp_xmit, &stats);
+ stats.rx.packets++;
}
}
@@ -1271,11 +1282,16 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
}
u64_stats_update_begin(&rq->stats.syncp);
- rq->stats.bytes += bytes;
- rq->stats.packets += received;
+ for (i = 0; i < VIRTNET_RQ_STATS_LEN; i++) {
+ size_t offset = virtnet_rq_stats_desc[i].offset;
+ u64 *item;
+
+ item = (u64 *)((u8 *)&rq->stats.items + offset);
+ *item += *(u64 *)((u8 *)&stats.rx + offset);
+ }
u64_stats_update_end(&rq->stats.syncp);
- return received;
+ return stats.rx.packets;
}
static void free_old_xmit_skbs(struct send_queue *sq)
@@ -1628,8 +1644,8 @@ static void virtnet_stats(struct net_device *dev,
do {
start = u64_stats_fetch_begin_irq(&rq->stats.syncp);
- rpackets = rq->stats.packets;
- rbytes = rq->stats.bytes;
+ rpackets = rq->stats.items.packets;
+ rbytes = rq->stats.items.bytes;
} while (u64_stats_fetch_retry_irq(&rq->stats.syncp, start));
tot->rx_packets += rpackets;
@@ -2019,7 +2035,7 @@ static void virtnet_get_ethtool_stats(struct net_device *dev,
for (i = 0; i < vi->curr_queue_pairs; i++) {
struct receive_queue *rq = &vi->rq[i];
- stats_base = (u8 *)&rq->stats;
+ stats_base = (u8 *)&rq->stats.items;
do {
start = u64_stats_fetch_begin_irq(&rq->stats.syncp);
for (j = 0; j < VIRTNET_RQ_STATS_LEN; j++) {
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 1/6] virtio_net: Fix incosistent received bytes counter
From: Toshiaki Makita @ 2018-07-23 14:36 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: Toshiaki Makita, netdev, virtualization
In-Reply-To: <20180723143609.2242-1-toshiaki.makita1@gmail.com>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
When received packets are dropped in virtio_net driver, received packets
counter is incremented but bytes counter is not.
As a result, for instance if we drop all packets by XDP, only received
is counted and bytes stays 0, which looks inconsistent.
IMHO received packets/bytes should be counted if packets are produced by
the hypervisor, like what common NICs on physical machines are doing.
So fix the bytes counter.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
drivers/net/virtio_net.c | 41 +++++++++++++++++++++++------------------
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 2ff08bc103a9..abbd3bc83b62 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -586,7 +586,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
struct receive_queue *rq,
void *buf, void *ctx,
unsigned int len,
- unsigned int *xdp_xmit)
+ unsigned int *xdp_xmit,
+ unsigned int *rbytes)
{
struct sk_buff *skb;
struct bpf_prog *xdp_prog;
@@ -601,6 +602,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
int err;
len -= vi->hdr_len;
+ *rbytes += len;
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -705,11 +707,13 @@ static struct sk_buff *receive_big(struct net_device *dev,
struct virtnet_info *vi,
struct receive_queue *rq,
void *buf,
- unsigned int len)
+ unsigned int len,
+ unsigned int *rbytes)
{
struct page *page = buf;
struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
+ *rbytes += len - vi->hdr_len;
if (unlikely(!skb))
goto err;
@@ -727,7 +731,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
void *buf,
void *ctx,
unsigned int len,
- unsigned int *xdp_xmit)
+ unsigned int *xdp_xmit,
+ unsigned int *rbytes)
{
struct virtio_net_hdr_mrg_rxbuf *hdr = buf;
u16 num_buf = virtio16_to_cpu(vi->vdev, hdr->num_buffers);
@@ -740,6 +745,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
int err;
head_skb = NULL;
+ *rbytes += len - vi->hdr_len;
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
@@ -877,6 +883,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
goto err_buf;
}
+ *rbytes += len;
page = virt_to_head_page(buf);
truesize = mergeable_ctx_to_truesize(ctx);
@@ -932,6 +939,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
dev->stats.rx_length_errors++;
break;
}
+ *rbytes += len;
page = virt_to_head_page(buf);
put_page(page);
}
@@ -942,14 +950,13 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
return NULL;
}
-static int receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
- void *buf, unsigned int len, void **ctx,
- unsigned int *xdp_xmit)
+static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
+ void *buf, unsigned int len, void **ctx,
+ unsigned int *xdp_xmit, unsigned int *rbytes)
{
struct net_device *dev = vi->dev;
struct sk_buff *skb;
struct virtio_net_hdr_mrg_rxbuf *hdr;
- int ret;
if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
pr_debug("%s: short packet %i\n", dev->name, len);
@@ -961,23 +968,22 @@ static int receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
} else {
put_page(virt_to_head_page(buf));
}
- return 0;
+ return;
}
if (vi->mergeable_rx_bufs)
- skb = receive_mergeable(dev, vi, rq, buf, ctx, len, xdp_xmit);
+ skb = receive_mergeable(dev, vi, rq, buf, ctx, len, xdp_xmit,
+ rbytes);
else if (vi->big_packets)
- skb = receive_big(dev, vi, rq, buf, len);
+ skb = receive_big(dev, vi, rq, buf, len, rbytes);
else
- skb = receive_small(dev, vi, rq, buf, ctx, len, xdp_xmit);
+ skb = receive_small(dev, vi, rq, buf, ctx, len, xdp_xmit, rbytes);
if (unlikely(!skb))
- return 0;
+ return;
hdr = skb_vnet_hdr(skb);
- ret = skb->len;
-
if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID)
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -994,12 +1000,11 @@ static int receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
ntohs(skb->protocol), skb->len, skb->pkt_type);
napi_gro_receive(&rq->napi, skb);
- return ret;
+ return;
frame_err:
dev->stats.rx_frame_errors++;
dev_kfree_skb(skb);
- return 0;
}
/* Unlike mergeable buffers, all buffers are allocated to the
@@ -1249,13 +1254,13 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
while (received < budget &&
(buf = virtqueue_get_buf_ctx(rq->vq, &len, &ctx))) {
- bytes += receive_buf(vi, rq, buf, len, ctx, xdp_xmit);
+ receive_buf(vi, rq, buf, len, ctx, xdp_xmit, &bytes);
received++;
}
} else {
while (received < budget &&
(buf = virtqueue_get_buf(rq->vq, &len)) != NULL) {
- bytes += receive_buf(vi, rq, buf, len, NULL, xdp_xmit);
+ receive_buf(vi, rq, buf, len, NULL, xdp_xmit, &bytes);
received++;
}
}
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 0/6] virtio_net: Add ethtool stat items
From: Toshiaki Makita @ 2018-07-23 14:36 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: Toshiaki Makita, netdev, virtualization
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Add some ethtool stat items useful for performance analysis.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Toshiaki Makita (6):
virtio_net: Fix incosistent received bytes counter
virtio_net: Use temporary storage for accounting rx stats
virtio_net: Make drop counter per-queue
virtio_net: Factor out the logic to determine xdp sq
virtio_net: Add XDP related stats
virtio_net: Add kick stats
drivers/net/virtio_net.c | 221 +++++++++++++++++++++++++++++++++--------------
1 file changed, 158 insertions(+), 63 deletions(-)
--
2.14.3
^ permalink raw reply
* Re: [stable-4.14 01/23] blk-mq-sched: move actual dispatching into one helper
From: Greg KH @ 2018-07-23 14:36 UTC (permalink / raw)
To: Jens Axboe; +Cc: Jack Wang, stable, Ming Lei, Jack Wang
In-Reply-To: <6bc6f918-b49e-a78f-a3b9-14578c98d0dc@kernel.dk>
On Mon, Jul 23, 2018 at 08:31:31AM -0600, Jens Axboe wrote:
> 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?!
I already complained that you were not cc:ed on the 00/23 email :)
greg k-h
^ permalink raw reply
* Re: How to tell bitbake my prefered terminal in for devshell and access bitbake datastore?
From: MOHAMMAD RASIM @ 2018-07-23 15:37 UTC (permalink / raw)
To: Rudolf J Streif, yocto
In-Reply-To: <fa1281bd-1bb1-7126-d142-1ca4e599794a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
Thanks, the OE_TERMINALvariable did it for me
>You cannot access d if you mean that
I don't mean d the object but the variables that are accessed by
d.getVar method.
>all the variables are exported to the shell.
What variables exactly? I just tried to echo some of the machine config
and recipe variables and they don't exist inside the devshell
On 07/23/2018 06:05 PM, Rudolf J Streif wrote:
> You can use the variable OE_TERMINAL to choose your preferred terminal.
> By default it's set to auto and Bitbake figures out what terminal is
> available on your system. Please refer to the manual at:
> https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#var-OE_TERMINAL.
>
>> Also, is it possible to access bitbake datastore from inside the
> devshell(or devpyshell) ?
>
> You cannot access d if you mean that, however, all the variables are
> exported to the shell.
>
> :rjs
>
>
> On 07/23/2018 02:49 AM, MOHAMMAD RASIM wrote:
>> Hi,
>>
>> when running bitbake with a recipe and giving the devshell as a
>> command bitbake runs the devshell inside xterm, on my other machine it
>> runs tmux.
>>
>> looking at the openembedded source code here
>> https://github.com/openembedded/openembedded-core/blob/master/meta/lib/oe/terminal.py
>>
>> I can see there are multiple classes for terminals that bitbake loop
>> through, but how can I tell bitbake that I prefer a certain terminal?
>>
>> Also, is it possible to access bitbake datastore from inside the
>> devshell(or devpyshell) ?
>>
>> Regards
>>
[-- Attachment #2: Type: text/html, Size: 2512 bytes --]
^ 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.