[patch net-next 3/3] net/sched: Change act_api and act_xxx modules to use IDR

Typically, each TC filter has its own action. All the actions of the same type are saved in its hash table. But the hash buckets are too small that it degrades to a list. And the performance is greatly affected. For example, it takes about 0m11.914s to insert 64K rules. If we convert the hash

[patch net-next 2/3] net/sched: Change cls_flower to use IDR

Currently, all filters with the same priority are linked in a doubly linked list. Every filter should have a unique handle. To make the handle unique, we need to iterate the list every time to see if the handle exists or not when inserting a new filter. It is time-consuming. For example, it takes

[patch net-next 0/3] net/sched: Improve getting objects by indexes

Using current TC code, it is very slow to insert a lot of rules. In order to improve the rules update rate in TC, we introduced the following two changes: 1) changed cls_flower to use IDR to manage the filters. 2) changed all act_xxx modules to use IDR instead of a

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, 15 Aug 2017 08:47:43 -0700 "Paul E. McKenney" wrote: > On Wed, Aug 02, 2017 at 05:25:55PM +0100, Jonathan Cameron wrote: > > On Tue, 1 Aug 2017 11:46:46 -0700 > > "Paul E. McKenney" wrote: > > > > > On Mon, Jul 31, 2017 at

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Tue, 2017-08-15 at 10:37 -0600, Alex Williamson wrote: > Of course I don't think either of those are worth imposing a > performance penalty where we don't otherwise need one. However, if we > look at a VM scenario where the guest is following the PCI standard for > programming MSI-X interrupts

Re: [PATCH v2 8/9] powerpc/64: Use a table of paca pointers and allocate pacas individually

Hi Nicholas, [auto build test ERROR on v4.13-rc5] [also build test ERROR on next-20170815] [cannot apply to powerpc/next scottwood/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nicholas

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Mon, 14 Aug 2017 14:12:33 +0100 Robin Murphy wrote: > On 14/08/17 10:45, Alexey Kardashevskiy wrote: > > Folks, > > > > Is there anything to change besides those compiler errors and David's > > comment in 5/5? Or the while patchset is too bad? Thanks. > > While I now

Re: [PATCH v2 8/9] powerpc/64: Use a table of paca pointers and allocate pacas individually

On Sun, 13 Aug 2017 11:33:45 +1000 Nicholas Piggin wrote: > Change the paca array into an array of pointers to pacas. Allocate > pacas individually. > > This allows flexibility in where the PACAs are allocated. Future work > will allocate them node-local. Platforms that don't

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Wed, Aug 02, 2017 at 05:25:55PM +0100, Jonathan Cameron wrote: > On Tue, 1 Aug 2017 11:46:46 -0700 > "Paul E. McKenney" wrote: > > > On Mon, Jul 31, 2017 at 04:27:57PM +0100, Jonathan Cameron wrote: > > > On Mon, 31 Jul 2017 08:04:11 -0700 > > > "Paul E. McKenney"

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

From: Benjamin Herrenschmidt > Sent: 15 August 2017 02:34 > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > Taking a step back, though, why does vfio-pci perform this check in the > > > first place? If a malicious guest already has control of a device, any > > > kind of interrupt

Re: [PATCH 05/11] serial: uuc_uart: constify uart_ops structures

On 8/13/17 1:21 AM, Julia Lawall wrote: These uart_ops structures are only stored in the ops field of a uart_port structure and this fields is const, so the uart_ops structures can also be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall Acked-by:

Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()

On 08/14/2017 11:02 PM, Michael Ellerman wrote: Khalid Aziz writes: On 08/10/2017 07:20 AM, Michael Ellerman wrote: Khalid Aziz writes: A protection flag may not be valid across entire address space and hence arch_validate_prot() might need

Re: [PATCH 2/2] of: Restrict DMA configuration

On Tue, Aug 15, 2017 at 5:18 AM, Robin Murphy wrote: > On 14/08/17 21:08, Rob Herring wrote: >> +linuxppc-dev >> >> On Fri, Aug 11, 2017 at 11:29 AM, Robin Murphy wrote: >>> Moving DMA configuration to happen later at driver probe time had the >>>

should "linux-phandle" be "linux,phandle"?

pedantic nitpickery but, in arch/powerpc/kernel/prom_init.c, line 2426, should that diagnostic message print "" and not ""? rday

Re: [PATCH v4 1/3] mm/hugetlb: Allow arch to override and call the weak function

"Aneesh Kumar K.V" writes: > When running in guest mode ppc64 supports a different mechanism for hugetlb > allocation/reservation. The LPAR management application called HMC can > be used to reserve a set of hugepages and we pass the details of > reserved pages

Re: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations

On Tue, 15 Aug 2017 22:48:22 +1000 Benjamin Herrenschmidt wrote: > On Tue, 2017-08-15 at 22:10 +1000, Nicholas Piggin wrote: > > On Mon, 14 Aug 2017 23:13:07 +1000 > > Benjamin Herrenschmidt wrote: > > > > > On Mon, 2017-08-14 at 22:49 +1000, Michael

Re: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations

On Tue, 2017-08-15 at 22:10 +1000, Nicholas Piggin wrote: > On Mon, 14 Aug 2017 23:13:07 +1000 > Benjamin Herrenschmidt wrote: > > > On Mon, 2017-08-14 at 22:49 +1000, Michael Ellerman wrote: > > > > - /* > > > > - * We limit the allocation that depend on

Re: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations

On Mon, 14 Aug 2017 23:13:07 +1000 Benjamin Herrenschmidt wrote: > On Mon, 2017-08-14 at 22:49 +1000, Michael Ellerman wrote: > > > - /* > > > - * We limit the allocation that depend on ppc64_rma_size > > > - * to first_memblock_size. We also clamp it to 1GB to >

Re: [PATCH v2 1/9] KVM: PPC: Book3S HV: Fix H_REGISTER_VPA VPA size validation

Nicholas Piggin writes: > KVM currently validates the size of the VPA registered by the client > against sizeof(struct lppaca), however we align (and therefore size) > that struct to 1kB to avoid crossing a 4kB boundary in the client. > > PAPR calls for sizes >= 640 bytes to

Re: [PATCH] powerpc: store the intended structure

Julia Lawall writes: > Normally the values in the resource field and the argument to ARRAY_SIZE > in the num_resources are the same. In this case, the value in the reousrce > field is the same as the one in the previous platform_device structure, and > appears to be a

Re: [PATCH 05/11] ASoC: omap: make snd_soc_platform_driver const

 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 2017-08-14 14:38, Bhumika Goyal wrote: > Make this const as it is only passed as the 2nd argument to the > function devm_snd_soc_register_platform, which is of

Re: [PATCH v6 1/2] powerpc/fadump: reduce memory consumption for capture kernel

Hello, sorry about the late reply. Looks like I had too much faith in the parse_args sanity. Looking closely the parsing happens in next_arg and only outermost quotes are removed. So presumably >>foo="bar baz"<< gives >>bar baz<< as value and >>foo=bar" baz"<< gives >>bar" baz<< as value.

Re: [PATCH 2/2] of: Restrict DMA configuration

On 14/08/17 21:08, Rob Herring wrote: > +linuxppc-dev > > On Fri, Aug 11, 2017 at 11:29 AM, Robin Murphy wrote: >> Moving DMA configuration to happen later at driver probe time had the >> unnoticed side-effect that we now perform DMA configuration for *every* >> device

Re: [PATCH] powerpc/xmon: Exclude all of xmon/ from ftrace

Michael Ellerman writes: > "Naveen N. Rao" writes: > >> diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile >> index 0b2f771593eb..5f95af64cb8f 100644 >> --- a/arch/powerpc/xmon/Makefile >> +++ b/arch/powerpc/xmon/Makefile

Re: [v6 15/15] mm: debug for raw alloctor

On Mon 14-08-17 10:01:52, Pasha Tatashin wrote: > >>However, now thinking about it, I will change it to CONFIG_MEMBLOCK_DEBUG, > >>and let users decide what other debugging configs need to be enabled, as > >>this is also OK. > > > >Actually the more I think about it the more I am convinced that a

Re: [v6 05/15] mm: don't accessed uninitialized struct pages

[CC Mel - the original patch was http://lkml.kernel.org/r/1502138329-123460-6-git-send-email-pasha.tatas...@oracle.com] On Mon 07-08-17 16:38:39, Pavel Tatashin wrote: > In deferred_init_memmap() where all deferred struct pages are initialized > we have a check like this: > > if

[PATCH v2 0/1] rtc: rtctest: Support opal-rtc and rtc-generic

On ppc64le machines the opal-rtc, resp rtc-generic in guest is used. They only support minimal set of functionality and fail this test in not-yet treated way. This extends the checks and skips to the next test when feature is not supported. Changes in v2: - Removed the double EINVAL check - Added

[PATCH v2 1/1] rtc: rtctest: Improve support detection

The rtc-generic and opal-rtc are failing to run this test as they do not support all the features. Let's treat the error returns and skip to the following test. Theoretically the test_DATE should be also adjusted, but as it's enabled on demand I think it makes sense to fail in such case.

Re: [PATCH 01/11] ASoC: codecs: make snd_soc_platform_driver const

On Mon, Aug 14, 2017 at 05:08:40PM +0530, Bhumika Goyal wrote: > Make these const as they are either passed as the 2nd argument to the > function devm_snd_soc_register_platform or snd_soc_register_platform, > and the arguments are of type const. > Done using Coccinelle. > > Signed-off-by: Bhumika

Re: [PATCH] rtc: rtctest: Improve support detection

Dne 12.8.2017 v 22:22 Alexandre Belloni napsal(a): > Hi, > > On 11/08/2017 at 11:14:55 +0200, Lukáš Doktor wrote: >> The rtc-generic and opal-rtc are failing to run this test as they do not >> support all the features. Let's treat the error returns and skip to the >> following test. >> >>

Re: [PATCH 05/11] ASoC: omap: make snd_soc_platform_driver const

On Mon, Aug 14, 2017 at 05:08:44PM +0530, Bhumika Goyal wrote: > Make this const as it is only passed as the 2nd argument to the > function devm_snd_soc_register_platform, which is of type const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal > --- >