Processors which have self-snooping capability can handle conflicting
memory type across CPUs by snooping its own cache. However, there exists
CPU models in which having conflicting memory types still leads to
unpredictable behavior, machine check errors, or hangs. Clear this feature
to prevent its
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also involves flushing
caches and TLBs twice. As a result, the process may take a considerable
amount of
With Roman's kmem cache reparent patch, multiple kmem caches of the same
type can be seen attached to the same memcg id. All of them, except
maybe one, are reparent'ed kmem caches. It can be useful to tag those
reparented caches by adding a new slab flag "SLAB_DEACTIVATED" to those
kmem caches that
On 6/26/19 3:58 PM, Roman Gushchin wrote:
> On Fri, Jun 21, 2019 at 01:30:05PM -0400, Waiman Long wrote:
>> With Roman's kmem cache reparent patch, multiple kmem caches of the same
>> type can be seen attached to the same memcg id. All of them, except
>> maybe one, are reparent'ed kmem caches. It c
On Mon, Jun 24, 2019 at 11:17:38AM +0800, zhe...@windriver.com wrote:
> From: He Zhe
>
> Since v5.1-rc1, some types of packets do not get unreachable reply with the
> following iptables setting. Fox example,
>
> $ iptables -A INPUT -p icmp --icmp-type 8 -j REJECT
> $ ping 127.0.0.1 -c 1
> PING 1
On Thu, Jun 27, 2019 at 02:27:22PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > > wrote:
> > > >
> > > > On Thu, Jun 27,
From: root
Fix following sparse warning
symbol was not declared. Should it be static?
Using plain integer as NULL pointer
Signed-off-by: Harsh Jain
---
drivers/staging/kpc2000/kpc_i2c/i2c_driver.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/kpc20
On Thu, 2019-06-27 at 11:09 -0700, Mike Kravetz wrote:
> On 6/24/19 2:53 PM, Mike Kravetz wrote:
> > On 6/24/19 2:30 PM, Qian Cai wrote:
> > > So the problem is that ipcget_public() has held the semaphore
> > > "ids->rwsem"
> > > for
> > > too long seems unnecessarily and then goes to sleep somet
On Thu, Jun 27, 2019 at 11:29 AM Dan Williams wrote:
>
> On Thu, Jun 27, 2019 at 9:06 AM Dan Williams wrote:
> >
> > On Thu, Jun 27, 2019 at 5:34 AM Matthew Wilcox wrote:
> > >
> > > On Wed, Jun 26, 2019 at 05:15:45PM -0700, Dan Williams wrote:
> > > > Ever since the conversion of DAX to the Xar
On Thu, Jun 27, 2019 at 11:58 AM Dan Williams wrote:
>
> On Thu, Jun 27, 2019 at 11:29 AM Dan Williams
> wrote:
> >
> > On Thu, Jun 27, 2019 at 9:06 AM Dan Williams
> > wrote:
> > >
> > > On Thu, Jun 27, 2019 at 5:34 AM Matthew Wilcox
> > > wrote:
> > > >
> > > > On Wed, Jun 26, 2019 at 05:1
There are some people interested in experimenting with Clang's
integrated assembler. To make it easy to do so without source
modification, allow the user to specify 'AS=clang' as part of the
make command to avoid adding '-no-integrated-as' to the {A,C}FLAGS.
Link: https://github.com/ClangBuiltLinu
On Thu, Jun 27, 2019 at 02:51:03PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 02:27:22PM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > > On Thu, Jun 27, 2019
On Thu, Jun 27, 2019 at 02:27:22PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > > wrote:
> > > >
> > > > On Thu, Jun 27,
On Mon, Jun 03, 2019 at 03:11:58PM -0700, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-un
On 5/30/19 12:30 AM, Andrew Jeffery wrote:
On Thu, 30 May 2019, at 03:40, Eddie James wrote:
Document the bindings.
Signed-off-by: Eddie James
---
.../devicetree/bindings/soc/aspeed/xdma.txt| 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documen
On Tue, 25 Jun 2019 20:59:45 +0300
Ivan Khoronzhuk wrote:
> Add user counter allowing to delete pool only when no users.
> It doesn't prevent pool from flush, only prevents freeing the
> pool instance. Helps when no need to delete the pool and now
> it's user responsibility to free it by calling
Tegra's APB DMA engine updates words counter after each transferred burst
of data, hence it can report transfer's residual with more fidelity which
may be required in cases like audio playback. In particular this fixes
audio stuttering during playback in a chromium web browser. The patch is
based o
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications,
Ping.
On Wed, 2019-06-05 at 16:53 -0400, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warnings,
>
> arch/powerpc/kernel/setu
Fixes issues found by checkpatch:
- "WARNING: braces {} are not necessary for single statement blocks"
- "WARNING: braces {} are not necessary for any arm of this statement"
Signed-off-by: Simon Sandström
---
drivers/staging/kpc2000/kpc2000_spi.c | 39 ++-
1 file changed
Ping.
On Thu, 2019-06-06 at 09:58 -0400, Qian Cai wrote:
> The powerpc's flush_cache_vmap() is defined as a macro and never use
> both of its arguments, so it will generate a compilation warning,
>
> lib/ioremap.c: In function 'ioremap_page_range':
> lib/ioremap.c:203:16: warning: variable 'start
The cpu-map DT entry in ARM can describe the CPU topology in much better
way compared to other existing approaches. RISC-V can easily adopt this
binding to represent its own CPU topology. Thus, both cpu-map DT
binding and topology parsing code can be moved to a common location so
that RISC-V or any
From: Sudeep Holla
Commit 5d777b185f6d ("arch_topology: Make cpu_capacity sysfs node as read-only")
made cpu_capacity sysfs node read-only. Update the GENERIC_ARCH_TOPOLOGY
Kconfig help section to reflect the same.
Cc: Greg Kroah-Hartman
Signed-off-by: Sudeep Holla
---
drivers/base/Kconfig |
Ping.
On Wed, 2019-06-05 at 16:46 -0400, Qian Cai wrote:
> The opening comment mark "/**" is reserved for kernel-doc comments, so
> it will generate a warning with "make W=1".
>
> arch/powerpc/kernel/eeh_cache.c:37: warning: cannot understand function
> prototype: 'struct pci_io_addr_range
>
> S
Currently, there are no topology defined for RISC-V.
Parse the cpu-map node from device tree and setup the
cpu topology.
CPU topology after applying the patch.
$cat /sys/devices/system/cpu/cpu2/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/core_siblings_list
0-3
$cat /
From: Sudeep Holla
arm and arm64 shared lot of CPU topology related code. This was
consolidated under driver/base/arch_topology.c by Juri. Now RISC-V
is also started sharing the same code pulling more code from arm64
into arch_topology.c
Since I was involved in the review from the beginning, I w
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.
The relevant discussion can be found here.
https://lkml.org/lkml/2018/11/6/19
Signed-off-by: Atish Patra
Reviewed-by: Sudeep Holla
Reviewed-by: Rob
Both RISC-V & ARM64 are using cpu-map device tree to describe
their cpu topology. It's better to move the relevant code to
a common place instead of duplicate code.
To: Will Deacon
To: Catalin Marinas
Signed-off-by: Atish Patra
[Tested on QDF2400]
Tested-by: Jeffrey Hugo
[Tested on Juno and ot
On Fri 2019-06-28 01:40:48, Fuqian Huang wrote:
> kmalloc + memset(0) -> kzalloc
>
> Signed-off-by: Fuqian Huang
Acked-by: Pavel Machek
> @@ -974,12 +974,11 @@ static int get_swap_reader(struct swap_map_handle
> *handle,
> last = handle->maps = NULL;
> offset = swsusp_header->imag
Currently, ARM32 and ARM64 uses different data structures to represent
their cpu topologies. Since, we are moving the ARM64 topology to common
code to be used by other architectures, we can reuse that for ARM32 as
well.
Take this opprtunity to remove the redundant functions from ARM32 and
reuse th
From: Sudeep Holla
The current ARM DT topology description provides the operating system
with a topological view of the system that is based on leaf nodes
representing either cores or threads (in an SMT system) and a
hierarchical set of cluster nodes that creates a hierarchical topology
view of h
On Wed, 2019-06-26 at 19:18 -0700, Atish Patra wrote:
> On 6/26/19 5:31 PM, Paul Walmsley wrote:
> > Hi Sudeep, Atish,
> >
> > On Mon, 17 Jun 2019, Atish Patra wrote:
> >
> > > From: Sudeep Holla
> > >
> > > The current ARM DT topology description provides the operating
> > > system
> > > with
On Thu, Jun 27, 2019 at 12:09:29PM -0700, Dan Williams wrote:
> > This bug feels like we failed to unlock, or unlocked the wrong entry
> > and this hunk in the bisected commit looks suspect to me. Why do we
> > still need to drop the lock now that the radix_tree_preload() calls
> > are gone?
>
> N
On 6/27/19 1:44 PM, Fuqian Huang wrote:
> pci_alloc_consistent calls dma_alloc_coherent directly.
> In commit af7ddd8a627c
> ("Merge tag 'dma-mapping-4.21' of
> git://git.infradead.org/users/hch/dma-mapping"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
>
> Sign
On Thu, 2019-06-27 at 15:52 -0400, Qian Cai wrote:
> On Wed, 2019-06-05 at 16:53 -0400, Qian Cai wrote:
> > At the beginning of setup_64.c, it has,
> >
> > #ifdef DEBUG
> > #define DBG(fmt...) udbg_printf(fmt)
> > #else
> > #define DBG(fmt...)
> > #endif
> >
> > where DBG() could be com
On Thu, 2019-06-27 at 11:00 -0700, Paul E. McKenney wrote:
> On Wed, Jun 26, 2019 at 11:49:16AM -0500, Scott Wood wrote:
> > On Wed, 2019-06-26 at 11:08 -0400, Steven Rostedt wrote:
> > > On Fri, 21 Jun 2019 16:59:55 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > I have no objection to the o
On 6/27/19 2:06 PM, James Morris wrote:
On Thu, 27 Jun 2019, Stephen Smalley wrote:
There are two scenarios where finer-grained distinctions make sense:
- Users may need to enable specific functionality that falls under the
umbrella of "confidentiality" or "integrity" lockdown. Finer-grained
On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 02:16:38PM -0400, Joel Fernandes wrote:
> >
> > I think the fix should be to prevent the wake-up not based on whether we
> > are
> > in hard/soft-interrupt mode but that we are doing the rcu_read_unlock()
> > from
Dave Chiluk writes:
> On Mon, Jun 24, 2019 at 10:33:07AM -0700, bseg...@google.com wrote:
>> This still has a similar cost as reducing min_cfs_rq_runtime to 0 - we
>> now take a tg-global lock on every group se dequeue. Setting min=0 means
>> that we have to take it on both enqueue and dequeue, w
On Wed, Jun 26, 2019 at 12:21:49PM -0400, J. Bruce Fields wrote:
> On Mon, Jun 24, 2019 at 05:05:12PM -0400, J. Bruce Fields wrote:
> > On Sat, Jun 22, 2019 at 01:22:56PM -0700, Kees Cook wrote:
> > > On Sat, Jun 22, 2019 at 03:00:58PM -0400, J. Bruce Fields wrote:
> > > > The logic around ESCAPE_N
This tests compares the amount of time that takes to read an entire
table of 100K elements on a bpf hashmap using both BPF_MAP_DUMP and
BPF_MAP_GET_NEXT_KEY + BPF_MAP_LOOKUP_ELEM.
Signed-off-by: Brian Vazquez
---
tools/testing/selftests/bpf/test_maps.c | 71 +
1 file chan
Make libbpf aware of new BPF_MAP_DUMP command and add bpf_map_dump and
bpf_map_dump_flags to use them from the library.
Suggested-by: Stanislav Fomichev
Signed-off-by: Brian Vazquez
---
tools/lib/bpf/bpf.c | 28
tools/lib/bpf/bpf.h | 4
tools/lib/bpf
Move reusable code from map_lookup_elem to helper functions to avoid code
duplication in kernel/bpf/syscall.c
Suggested-by: Stanislav Fomichev
Signed-off-by: Brian Vazquez
---
kernel/bpf/syscall.c | 134 +++
1 file changed, 73 insertions(+), 61 deletions(
This introduces a new command to retrieve a variable number of entries
from a bpf map wrapping the existing bpf methods:
map_get_next_key and map_lookup_elem
Note that map_dump doesn't guarantee that reading the entire table is
consistent since this function is always racing with kernel and user c
Adds bpf_attr.dump structure to libbpf.
Suggested-by: Stanislav Fomichev
Signed-off-by: Brian Vazquez
---
tools/include/uapi/linux/bpf.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index b077507efa3f3..1d753958874d
This introduces a new command to retrieve a variable number of entries
from a bpf map.
This new command can be executed from the existing BPF syscall as
follows:
err = bpf(BPF_MAP_DUMP, union bpf_attr *attr, u32 size)
using attr->dump.map_fd, attr->dump.prev_key, attr->dump.buf,
attr->dump.buf_l
This tests exercise the new command on a bpf hashmap and make sure it
works as expected.
Signed-off-by: Brian Vazquez
---
tools/testing/selftests/bpf/test_maps.c | 70 -
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_maps.c
The following changes since commit 1cc54078d104f5b4d7e9f8d55362efa5a8daffdb:
clk: ti: clkctrl: Fix clkdm_clk handling (2019-05-21 11:43:40 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
tags/clk-fixes-for-linus
for you to fetch
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Jarkko Sakkinen
> Sent: Tuesday, June 25, 2019 8:44 AM
>
> I went through the vDSO changes just to revisit couple of details that I
> had forgotten. Sean, if you don't mind I'd squash this and prependi
On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 02:16:38PM -0400, Joel Fernandes wrote:
> > >
> > > I think the fix should be to prevent the wake-up not based on whether we
> > > are
> > > in hard/
Hi Yamada-san,
On Thu, Jun 27, 2019 at 12:01 AM Masahiro Yamada
wrote:
>
> Xtensa does not define CONFIG_64BIT. The generic definition in
> include/asm-generic/bitsperlong.h should work.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/xtensa/include/asm/types.h | 8
> 1 file changed,
Ricardo,
On Thu, 27 Jun 2019, Ricardo Neri wrote:
>
> +/*
> + * Processors which have self-snooping capability can handle conflicting
> + * memory type across CPUs by snooping its own cache. However, there exists
> + * CPU models in which having conflicting memory types still leads to
> + * unpr
On Thu, 27 Jun 2019, Ricardo Neri wrote:
> By measuring the execution time of mtrr_aps_init() (from which MTRRs
> in all CPUs are programmed in lock-step at boot), I find savings in the
> time required to program MTRRs as follows:
>
> Platform time-with-wbinvd(ms) time-no-wbin
btrfs is going to use css_put() and wbc helpers to improve cgroup
writeback support. Add dummy css_get() definition and export wbc
helpers to prepare for module and !CONFIG_CGROUP builds.
Signed-off-by: Tejun Heo
Reported-by: kbuild test robot
Reviewed-by: Jan Kara
---
block/blk-cgroup.c
On Thu, Jun 27, 2019 at 12:48:27PM +0200, Christoph Hellwig wrote:
> Currently we don't overwrite the flags field in the iomap in
> xfs_bmbt_to_iomap. This works fine with 0-initialized iomaps on stack,
> but is harmful once we want to be able to reuse an iomap in the
> writeback code. Replace th
For ECs that support it, the EC returns the number of slp_s0
transitions and whether or not there was a timeout in the resume
response. Expose the last resume result to usermode via debugfs so
that usermode can detect and report S0ix timeouts.
Signed-off-by: Evan Green
---
Changes in v3:
- Expo
On Thu, Jun 27, 2019 at 11:30:22AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > > wrote:
> > > >
> > > > On Thu, Jun 2
On Thu, Jun 27, 2019 at 12:48:24PM +0200, Christoph Hellwig wrote:
> We have a very common pattern where we want to delete the first entry
> from a list and return it as the properly typed container structure.
>
> Add two helpers to implement this behavior.
>
> Signed-off-by: Christoph Hellwig
On Thu, Jun 27, 2019 at 03:16:09PM -0500, Scott Wood wrote:
> On Thu, 2019-06-27 at 11:00 -0700, Paul E. McKenney wrote:
> > On Wed, Jun 26, 2019 at 11:49:16AM -0500, Scott Wood wrote:
> > > On Wed, 2019-06-26 at 11:08 -0400, Steven Rostedt wrote:
> > > > On Fri, 21 Jun 2019 16:59:55 -0700
> > > >
Quoting Mike Looijmans (2019-05-07 06:51:10)
> The Si544 supports changing frequencies "on the fly" when the change is
> less than 950 ppm from the current center frequency. The driver now
> uses the small adjustment routine for implementing this.
>
> Signed-off-by: Mike Looijmans
> ---
Applied
Quoting Mike Looijmans (2019-06-27 04:38:16)
> On 26-06-19 23:24, Stephen Boyd wrote:
> > Sorry, I'm getting through my inbox pile and saw this one.
> >
> > Quoting Mike Looijmans (2019-04-30 22:46:55)
> >> On 30-04-19 02:17, Stephen Boyd wrote:
> >>>
> >>> Why can't that driver call clk_prepare_e
On Wed, Jun 19, 2019 at 12:49 PM David Howells wrote:
>
> Create key domain tags for network namespaces and make it possible to
> automatically tag keys that are used by networked services (e.g. AF_RXRPC,
> AFS, DNS) with the default network namespace if not set by the caller.
>
> This allows keys
On Thu, Jun 27, 2019 at 09:42:40AM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 04:07:46PM +0900, Byungchul Park wrote:
> > Hello,
> >
> > I tested if the WARN_ON_ONCE() is fired with my box and it was ok.
>
> Looks pretty safe to me and nice clean up!
>
> Acked-by: Joel Fernandes (Goo
Quoting Mike Looijmans (2019-05-17 06:20:20)
> Adds the devicetree bindings for the Si5341 and Si5340 chips from
> Silicon Labs. These are multiple-input multiple-output clock
> synthesizers.
>
> Signed-off-by: Mike Looijmans
>
> ---
Applied to clk-next
On 6/27/19 10:20 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Wed, Jun 26, 2019 at 12:56:14PM -0400, Waiman Long wrote:
>> With memory cgroup v1, there is a kmem.slabinfo file that can be
>> used to view what slabs are allocated to the memory cgroup. There
>> is currently no such equivalent in memo
The cpufreq_online and the cpufreq_offline [un]register the driver as
a cooling device. This is done if the driver is flagged as a cooling
device in addition with a IS_ENABLED macro to compile out the branching
code.
Group this test in a stub function added in the cpufreq header instead
of having
Currently the function cpufreq_cooling_register() returns a cooling
device pointer which is used back as a pointer to call the function
cpufreq_cooling_unregister(). Even if it is correct, it would make
sense to not leak the structure inside a cpufreq driver and keep the
code thermal code self-enca
It looks like after the changes in the patch the only reason for
returning (struct thermal_cooling_device *) from
cpufreq_cooling_register() is error checking, but it would be much
more straightforward to return int for this purpose.
Moreover, that would prevent the callers of it from doing incorr
Quoting Mike Looijmans (2019-05-17 06:23:52)
> Adds a driver for the Si5341 and Si5340 chips. The driver does not fully
> support all features of these chips, but allows the chip to be used
> without any support from the "clockbuilder pro" software.
>
> If the chip is preprogrammed, that is, you b
On Thu, 27 Jun 2019, Peter Xu wrote:
> + * @TIMER_PINNED: A pinned timer will not be affected by any timer
> + * placement heuristics (like, NOHZ) and will always be run on the CPU
> + * when the timer was enqueued.
s/when/on which/
> + *
> + * Note: Because enqueuing of timers can actually migra
IRQ numbers are always positive, hence the corresponding variable should
be unsigned to keep types consistent. This is a minor change that cleans
up code a tad more.
Suggested-by: Thierry Reding
Acked-by: MyungJoo Ham
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 8 +++
Now that all kHz-conversion related bugs are fixed, we can use the kHz
uniformly. This makes code cleaner and avoids integer divisions in the
code, which is useful in a case of Tegra30 that has Cortex A9 CPU that
doesn't support integer division instructions, hence all divisions are
actually made i
The EMC clock rate rounding technically could fail, hence let's handle
the error cases properly.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/driver
Add debug messages to know about what's happening in hardware and how
driver reacts.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegr
The memory activity counter may get a bit higher than a watermark which
is selected based on OPP that corresponds to a highest EMC rate, in this
case watermark is lower than the actual memory activity is and thus
results in unwanted "upper" interrupts.
Signed-off-by: Dmitry Osipenko
---
drivers/
When CPU's memory activity is low or memory activity is high such that
CPU's frequency contribution to the boosting is not taken into account,
then there is no need to schedule devfreq's update. This eliminates
unnecessary CPU activity during of idling caused by the scheduled work.
Signed-off-by:
Debug messages create too much CPU and memory activity by themselves,
so it's difficult to debug lower rates and catch unwanted interrupts
that happen rarely. Tracepoints are ideal in that regards because they
do not contribute to the sampled date at all. This allowed me to catch
few problems which
Potentially very high boosting could cause an integer overflow for a
highly clocked memory after conversion to MHz.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegra3
It's not very correct to include mod_devicetable.h for the OF device
drivers and of_device.h should be included instead.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/d
The consecutive-down event tells that we should perform frequency
de-boosting, but boosting is in a reset state on start and hence the
event won't do anything useful for us and it will be just a dummy
interrupt request.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 1 -
There is no real need to keep interrupt always-enabled, will be nicer
to keep it disabled while governor is inactive.
Suggested-by: Thierry Reding
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 43 ---
1 file changed, 22 insertions(+), 21 dele
I noticed that CPU may be crossing the dependency threshold very
frequently for some workloads and this results in a lot of interrupts
which could be avoided if MCALL client is keeping actual EMC frequency
at a higher rate.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 2
There is another kHz-conversion bug in the code, resulting in integer
overflow. Although, this time the resulting value is 4294966296 and it's
close to ULONG_MAX, which is okay in this case.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 2 +-
1 file changed, 1 insertion(
Constify unmodifiable structs for consistency.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegra30-devfreq.c
index ecbd58504cd8..d3e117d827d2 10
I was contributing to the NVIDIA Tegra20+ devfreq drivers recently and
want to help keep them working and evolving in the future.
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 792d2d927712..bfd827417a27
There is no need in a write-barrier now, given that interrupt masking is
handled by CPU's GIC now. Hence we know exactly that interrupt won't fire
after stopping the devfreq's governor. In other cases we don't care about
potential buffering of the writes to hardware and thus there is no need to
sta
Governor could be stopped while boosting is active. We have assumption
that everything is reset on governor's restart, including the boosting
value, which was missed.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drive
There is no point in receiving of the notifications while governor is
stopped, let's keep them disabled like we do for the CPU freq-change
notifications. This also fixes a potential use-after-free bug if
notification happens after device's removal.
Signed-off-by: Dmitry Osipenko
---
drivers/devf
Depending on a kernel's configuration, a single line functions may not be
inlined by compiler (like enabled ftracing for example). Let's inline such
functions explicitly for consistency.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 13 +++--
1 file changed, 7 in
Now that average-sustain coefficient / multiplier is gone, it won't hurt
to re-tune the boosting thresholds to get a bit harder boosting for MCALL
clients, resulting in a more reactive governing in a case of multimedia
applications usage like 3d / video.
Signed-off-by: Dmitry Osipenko
---
driver
The CPU's client need to take into account that CPUFreq may change
while memory activity not, staying high. Thus an appropriate frequency
notifier should be used in addition to the clk-notifier.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 105 +-
On Wed, Jun 26, 2019 at 04:52:36PM +0200, Sebastian Andrzej Siewior wrote:
> A small series of tiny cleanups.
Applied 1-2 to wq/for-5.3.
Thanks.
--
tejun
The current implementation is inaccurate and results in very intensive
interrupt activity, which neglects the whole idea of polling offload to
hardware. The reason of the shortcoming is that watermarks are not set
up correctly and this results in ACTMON constantly asking to change freq
and then the
Hello,
This series addresses some additional review comments that were made by
Thierry Reding to [1] and makes several important changes to the driver,
fixing excessive interrupts activity. In the end I'm proposing myself as
a maintainer for the Tegra devfreq drivers.
[1]
https://lore.kernel.org
Hi Evan, Lee,
Missatge de Evan Green del dia dj., 27 de juny
2019 a les 22:46:
>
> For ECs that support it, the EC returns the number of slp_s0
> transitions and whether or not there was a timeout in the resume
> response. Expose the last resume result to usermode via debugfs so
> that usermode c
mdio ahci libahci tg3 libphy libata firmware_class dm_mirror
dm_region_hash dm_log dm_mod
[ 1139.415595][ T5301] CPU: 67 PID: 5301 Comm: cat Not tainted 5.2.0-rc6-next-
20190627+ #19
[ 1139.415634][ T5301] NIP: c00d0d58 LR: c049aa18 CTR:
c00d0d50
[ 1139.415675][ T5301]
Hi Stephen,
Miquel Raynal wrote on Thu, 27 Jun 2019
16:51:37 +0200:
> Hi Stephen,
>
> Stephen Rothwell wrote on Tue, 4 Jun 2019
> 10:54:18 +1000:
>
> > Hi all,
> >
> > Today's linux-next merge of the nand tree got a conflict in:
> >
> > Documentation/devicetree/bindings/mtd/brcm,brcmnand.
On Wed, 26 Jun 2019, Zhenzhong Duan wrote:
> This reverts commit ca5d376e17072c1b60c3fee66f3be58ef018952d.
>
> Commit 8990cac6e5ea ("x86/jump_label: Initialize static branching
> early") adds jump_label_init() call in setup_arch() to make static
> keys initialized early, so we could use the origi
Such as those produced by the `patch` utility. We already ignore *.orig
files, and there are currently no *.rej files in the tree at this time.
Signed-off-by: Nick Desaulniers
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 7587ef56b92d..f97430cb2
On Thu, Jun 27, 2019 at 04:57:50PM -0400, Waiman Long wrote:
> On 6/26/19 4:19 PM, Roman Gushchin wrote:
> >>
> >> +#ifdef CONFIG_MEMCG_KMEM
> >> +static void kmem_cache_shrink_memcg(struct mem_cgroup *memcg,
> >> + void __maybe_unused *arg)
> >> +{
> >> + struct kme
601 - 700 of 1043 matches
Mail list logo
