* RE: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
From: David Laight @ 2020-02-20 14:39 UTC (permalink / raw)
To: 'chris hyser', Parth Shah, vincent.guittot@linaro.org,
patrick.bellasi@matbug.net, valentin.schneider@arm.com,
dhaval.giani@oracle.com, dietmar.eggemann@arm.com
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com, qais.yousef@arm.com, pavel@ucw.cz,
qperret@qperret.net, pjt@google.com, tj@kernel.org
In-Reply-To: <10f42efa-3750-491a-74fe-d84c9c4924e3@oracle.com>
From: chris hyser <chris.hyser@oracle.com>
> Sent: 19 February 2020 17:17
>
> On 2/19/20 6:18 AM, David Laight wrote:
> > From: chris hyser
> >> Sent: 18 February 2020 23:00
> > ...
> >> All, I was asked to take a look at the original latency_nice patchset.
> >> First, to clarify objectives, Oracle is not
> >> interested in trading throughput for latency.
> >> What we found is that the DB has specific tasks which do very little but
> >> need to do this as absolutely quickly as possible, ie extreme latency
> >> sensitivity. Second, the key to latency reduction
> >> in the task wakeup path seems to be limiting variations of "idle cpu" search.
> >> The latter particularly interests me as an example of "platform size
> >> based latency" which I believe to be important given all the varying size
> >> VMs and containers.
> >
> > From my experiments there are a few things that seem to affect latency
> > of waking up real time (sched fifo) tasks on a normal kernel:
>
> Sorry. I was only ever talking about sched_other as per the original patchset. I realize the term
> extreme latency
> sensitivity may have caused confusion. What that means to DB people is no doubt different than audio
> people. :-)
Shorter lines.....
ISTM you are making some already complicated code even more complex.
Better to make it simpler instead.
If you need a thread to run as soon as possible after it is woken
why not use the RT scheduler (eg SCHED_FIFO) that is what it is for.
If there are delays finding an idle cpu to migrate a process to
(especially on systems with large numbers of cpu) then that is a
general problem that can be addressed without extra knobs.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Roger Pau Monné @ 2020-02-20 14:38 UTC (permalink / raw)
To: Jürgen Groß
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Jan Beulich, xen-devel
In-Reply-To: <ac515c56-e391-3636-244d-4b660c615dee@suse.com>
On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
> On 20.02.20 15:11, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> > > On 20.02.2020 13:02, Roger Pau Monne wrote:
> > > > I've done some testing and at least the CPU down case is fixed now.
> > > > Posting early in order to get feedback on the approach taken.
> > >
> > > Looks good, thanks, just a question and two comments:
> > >
> > > > --- a/xen/include/xen/rwlock.h
> > > > +++ b/xen/include/xen/rwlock.h
> > > > @@ -20,21 +20,30 @@ typedef struct {
> > > > #define DEFINE_RWLOCK(l) rwlock_t l = RW_LOCK_UNLOCKED
> > > > #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
> > > > -/*
> > > > - * Writer states & reader shift and bias.
> > > > - *
> > > > - * Writer field is 8 bit to allow for potential optimisation, see
> > > > - * _write_unlock().
> > > > - */
> > > > -#define _QW_WAITING 1 /* A writer is waiting */
> > > > -#define _QW_LOCKED 0xff /* A writer holds the lock */
> > > > -#define _QW_WMASK 0xff /* Writer mask.*/
> > > > -#define _QR_SHIFT 8 /* Reader count shift */
> > > > +/* Writer states & reader shift and bias. */
> > > > +#define _QW_WAITING 1 /* A writer is waiting */
> > > > +#define _QW_LOCKED 3 /* A writer holds the lock */
> > >
> > > Aiui things would work equally well if 2 was used here?
> >
> > I think so, I left it as 3 because previously LOCKED would also
> > include WAITING, and I didn't want to change it in case I've missed
> > some code path that was relying on that.
> >
> > >
> > > > +#define _QW_WMASK 3 /* Writer mask */
> > > > +#define _QW_CPUSHIFT 2 /* Writer CPU shift */
> > > > +#define _QW_CPUMASK 0x3ffc /* Writer CPU mask */
> > >
> > > At least on x86, the shift involved here is quite certainly
> > > more expensive than using wider immediates on AND and CMP
> > > resulting from the _QW_MASK-based comparisons. I'd therefore
> > > like to suggest to put the CPU in the low 12 bits.
> >
> > Hm right. The LOCKED and WAITING bits don't need shifting anyway.
> >
> > >
> > > Another option is to use the recurse_cpu field of the
> > > associated spin lock: The field is used for recursive locks
> > > only, and hence the only conflict would be with
> > > _spin_is_locked(), which we don't (and in the future then
> > > also shouldn't) use on this lock.
> >
> > I looked into that also, but things get more complicated AFAICT, as it's
> > not possible to atomically fetch the state of the lock and the owner
> > CPU at the same time. Neither you could set the LOCKED bit and the CPU
> > at the same time.
> >
> > >
> > > > @@ -166,7 +180,8 @@ static inline void _write_unlock(rwlock_t *lock)
> > > > * If the writer field is atomic, it can be cleared directly.
> > > > * Otherwise, an atomic subtraction will be used to clear it.
> > > > */
> > > > - atomic_sub(_QW_LOCKED, &lock->cnts);
> > > > + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
> > > > + atomic_sub(_write_lock_val(), &lock->cnts);
> > >
> > > I think this would be more efficient with atomic_and(), not
> > > the least because of the then avoided smp_processor_id().
> > > Whether to mask off just _QW_WMASK or also the CPU number of
> > > the last write owner would need to be determined. But with
> > > using subtraction, in case of problems it'll likely be
> > > harder to understand what actually went on, from looking at
> > > the resulting state of the lock (this is in part a pre-
> > > existing problem, but gets worse with subtraction of CPU
> > > numbers).
> >
> > Right, a mask would be better. Right now both need to be cleared (the
> > LOCKED and the CPU fields) as there's code that relies on !lock->cnts
> > as a way to determine that the lock is not read or write locked. If we
> > left the CPU lying around those checks would need to be adjusted.
>
> In case you make _QR_SHIFT 16 it is possible to just write a 2-byte zero
> value for write_unlock() (like its possible to do so today using a
> single byte write).
That would limit the readers count to 65536, what do you think Jan?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [LTP] [PATCH] syscalls/ptrace: Merge ptrace01 and ptrace02
From: Cyril Hrubis @ 2020-02-20 14:39 UTC (permalink / raw)
To: ltp
In-Reply-To: <20200108135949.15048-1-jcronenberg@suse.de>
Hi!
Pushed with minor adjustements, thanks.
* Removed the runtest entry for ptrace02
* Removed the .gitignore entry for ptrace02
* Fixed the status handling at the end of the test
We should adjust our expectations based on which ptrace() call we did,
e.g. for PTRACE_CONT the child killed by sigkill is still a failure.
Also you have to call WIF*() first and only then you can get the
exit/term signal value.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* [PATCH] fstests: add a another gap extent testcase for btrfs
From: Josef Bacik @ 2020-02-20 14:38 UTC (permalink / raw)
To: linux-btrfs, kernel-team, fstests
This is a testcase for a corner that I missed when trying to fix gap
extents for btrfs. We would end up with gaps if we hole punched past
isize and then extended past the gap in a specific way. This is a
simple reproducer to show the problem, and has been properly fixed by my
patches now.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
tests/btrfs/204 | 85 +++++++++++++++++++++++++++++++++++++++++++++
tests/btrfs/204.out | 5 +++
tests/btrfs/group | 1 +
3 files changed, 91 insertions(+)
create mode 100755 tests/btrfs/204
create mode 100644 tests/btrfs/204.out
diff --git a/tests/btrfs/204 b/tests/btrfs/204
new file mode 100755
index 00000000..0d5c4bed
--- /dev/null
+++ b/tests/btrfs/204
@@ -0,0 +1,85 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2020 Facebook. All Rights Reserved.
+#
+# FS QA Test 204
+#
+# Validate that without no-holes we do not get a i_size that is after a gap in
+# the file extents on disk when punching a hole past i_size. This is fixed by
+# the following patches
+#
+# btrfs: use the file extent tree infrastructure
+# btrfs: replace all uses of btrfs_ordered_update_i_size
+#
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+ cd /
+ rm -f $tmp.*
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+. ./common/dmlogwrites
+
+# remove previous $seqres.full before test
+rm -f $seqres.full
+
+# real QA test starts here
+
+# Modify as appropriate.
+_supported_fs generic
+_supported_os Linux
+_require_test
+_require_scratch
+_require_log_writes
+
+_log_writes_init $SCRATCH_DEV
+_log_writes_mkfs "-O ^no-holes" >> $seqres.full 2>&1
+
+# There's not a straightforward way to commit the transaction without also
+# flushing dirty pages, so shorten the commit interval to 1 so we're sure to get
+# a commit with our broken file
+_log_writes_mount -o commit=1
+
+# This creates a gap extent because fpunch doesn't insert hole extents past
+# i_size
+xfs_io -f -c "falloc -k 4k 8k" $SCRATCH_MNT/file
+xfs_io -f -c "fpunch 4k 4k" $SCRATCH_MNT/file
+
+# The pwrite extends the i_size to cover the gap extent, and then the truncate
+# sets the disk_i_size to 12k because it assumes everything was a-ok.
+xfs_io -f -c "pwrite 0 4k" $SCRATCH_MNT/file | _filter_xfs_io
+xfs_io -f -c "pwrite 0 8k" $SCRATCH_MNT/file | _filter_xfs_io
+xfs_io -f -c "truncate 12k" $SCRATCH_MNT/file
+
+# Wait for a transaction commit
+sleep 2
+
+_log_writes_unmount
+_log_writes_remove
+
+cur=$(_log_writes_find_next_fua 0)
+echo "cur=$cur" >> $seqres.full
+while [ ! -z "$cur" ]; do
+ _log_writes_replay_log_range $cur $SCRATCH_DEV >> $seqres.full
+
+ # We only care about the fs consistency, so just run fsck, we don't have
+ # to mount the fs to validate it
+ _check_scratch_fs
+
+ cur=$(_log_writes_find_next_fua $(($cur + 1)))
+done
+
+# success, all done
+status=0
+exit
diff --git a/tests/btrfs/204.out b/tests/btrfs/204.out
new file mode 100644
index 00000000..44c7c8ae
--- /dev/null
+++ b/tests/btrfs/204.out
@@ -0,0 +1,5 @@
+QA output created by 204
+wrote 4096/4096 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 8192/8192 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
diff --git a/tests/btrfs/group b/tests/btrfs/group
index 6acc6426..7a840177 100644
--- a/tests/btrfs/group
+++ b/tests/btrfs/group
@@ -206,3 +206,4 @@
201 auto quick punch log
202 auto quick subvol snapshot
203 auto quick send clone
+204 auto quick log replay
--
2.24.1
^ permalink raw reply related
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 14:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann,
Suzuki K Poulose, Quentin Perret, Christoffer Dall,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, James Morse,
linux-arm-kernel, Paolo Bonzini, Will Deacon, kvmarm,
Julien Thierry, Marek Szyprowski
In-Reply-To: <3f7f3b6c8b758b6d2134364616c6bc1e@kernel.org>
On 20/02/2020 2:01 pm, Marc Zyngier wrote:
> On 2020-02-20 13:32, Robin Murphy wrote:
>> On 20/02/2020 1:15 pm, Marc Zyngier wrote:
>>> Hi Marek,
>>>
>>> On 2020-02-20 12:44, Marek Szyprowski wrote:
>>>> Hi Marc,
>>>>
>>>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>>>> life so far. It mostly works if you're prepared to deal with its
>>>>> limitations, it has been a good prototype for the arm64 version,
>>>>> but it suffers a few problems:
>>>>>
>>>>> - It is incomplete (no debug support, no PMU)
>>>>> - It hasn't followed any of the architectural evolutions
>>>>> - It has zero users (I don't count myself here)
>>>>> - It is more and more getting in the way of new arm64 developments
>>>>
>>>> That is a bit sad information. Mainline Exynos finally got everything
>>>> that was needed to run it on the quite popular Samsung Exynos5422-based
>>>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>>>> being used. We also use it internally at Samsung.
>>>
>>> Something like "too little, too late" springs to mind, but let's be
>>> constructive. Is anyone using it in a production environment, where
>>> they rely on the latest mainline kernel having KVM support?
>>>
>>> The current proposal is to still have KVM support in 5.6, as well as
>>> ongoing support for stable kernels. If that's not enough, can you please
>>> explain your precise use case?
>>
>> Presumably there's no *technical* reason why the stable subset of v7
>> support couldn't be stripped down and brought back private to arch/arm
>> if somebody really wants and is willing to step up and look after it?
>
> There is no technical reason at all, just a maintenance effort.
>
> The main killer is the whole MMU code, which I'm butchering with NV,
> and that I suspect Will will also turn upside down with his stuff.
> Not to mention the hypercall interface that will need a complete overhaul.
>
> If we wanted to decouple the two, we'd need to make the MMU code, the
> hypercalls, arm.c and a number of other bits private to 32bit.
Right, the prospective kvm-arm maintainer's gameplan would essentially
be an equivalent "move virt/kvm/arm to arch/arm/kvm" patch, but then
ripping out all the Armv8 and GICv3 gubbins instead. Yes, there would
then be lots of *similar* code to start with, but it would only diverge
further as v8 architecture development continues independently.
Anyway, I just thought it seemed worth saying out loud, to reassure
folks that a realistic middle-ground between "yay bye!" and "oh no the
end of the world!" does exist, namely "someone else's problem" :)
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 14:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm, Marek Szyprowski
In-Reply-To: <3f7f3b6c8b758b6d2134364616c6bc1e@kernel.org>
On 20/02/2020 2:01 pm, Marc Zyngier wrote:
> On 2020-02-20 13:32, Robin Murphy wrote:
>> On 20/02/2020 1:15 pm, Marc Zyngier wrote:
>>> Hi Marek,
>>>
>>> On 2020-02-20 12:44, Marek Szyprowski wrote:
>>>> Hi Marc,
>>>>
>>>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>>>> life so far. It mostly works if you're prepared to deal with its
>>>>> limitations, it has been a good prototype for the arm64 version,
>>>>> but it suffers a few problems:
>>>>>
>>>>> - It is incomplete (no debug support, no PMU)
>>>>> - It hasn't followed any of the architectural evolutions
>>>>> - It has zero users (I don't count myself here)
>>>>> - It is more and more getting in the way of new arm64 developments
>>>>
>>>> That is a bit sad information. Mainline Exynos finally got everything
>>>> that was needed to run it on the quite popular Samsung Exynos5422-based
>>>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>>>> being used. We also use it internally at Samsung.
>>>
>>> Something like "too little, too late" springs to mind, but let's be
>>> constructive. Is anyone using it in a production environment, where
>>> they rely on the latest mainline kernel having KVM support?
>>>
>>> The current proposal is to still have KVM support in 5.6, as well as
>>> ongoing support for stable kernels. If that's not enough, can you please
>>> explain your precise use case?
>>
>> Presumably there's no *technical* reason why the stable subset of v7
>> support couldn't be stripped down and brought back private to arch/arm
>> if somebody really wants and is willing to step up and look after it?
>
> There is no technical reason at all, just a maintenance effort.
>
> The main killer is the whole MMU code, which I'm butchering with NV,
> and that I suspect Will will also turn upside down with his stuff.
> Not to mention the hypercall interface that will need a complete overhaul.
>
> If we wanted to decouple the two, we'd need to make the MMU code, the
> hypercalls, arm.c and a number of other bits private to 32bit.
Right, the prospective kvm-arm maintainer's gameplan would essentially
be an equivalent "move virt/kvm/arm to arch/arm/kvm" patch, but then
ripping out all the Armv8 and GICv3 gubbins instead. Yes, there would
then be lots of *similar* code to start with, but it would only diverge
further as v8 architecture development continues independently.
Anyway, I just thought it seemed worth saying out loud, to reassure
folks that a realistic middle-ground between "yay bye!" and "oh no the
end of the world!" does exist, namely "someone else's problem" :)
Robin.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 14:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: Marek Szyprowski, Vladimir Murzin, Russell King, kvm,
Arnd Bergmann, Suzuki K Poulose, Quentin Perret, Christoffer Dall,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, James Morse,
Julien Thierry, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <3f7f3b6c8b758b6d2134364616c6bc1e@kernel.org>
On 20/02/2020 2:01 pm, Marc Zyngier wrote:
> On 2020-02-20 13:32, Robin Murphy wrote:
>> On 20/02/2020 1:15 pm, Marc Zyngier wrote:
>>> Hi Marek,
>>>
>>> On 2020-02-20 12:44, Marek Szyprowski wrote:
>>>> Hi Marc,
>>>>
>>>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>>>> life so far. It mostly works if you're prepared to deal with its
>>>>> limitations, it has been a good prototype for the arm64 version,
>>>>> but it suffers a few problems:
>>>>>
>>>>> - It is incomplete (no debug support, no PMU)
>>>>> - It hasn't followed any of the architectural evolutions
>>>>> - It has zero users (I don't count myself here)
>>>>> - It is more and more getting in the way of new arm64 developments
>>>>
>>>> That is a bit sad information. Mainline Exynos finally got everything
>>>> that was needed to run it on the quite popular Samsung Exynos5422-based
>>>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>>>> being used. We also use it internally at Samsung.
>>>
>>> Something like "too little, too late" springs to mind, but let's be
>>> constructive. Is anyone using it in a production environment, where
>>> they rely on the latest mainline kernel having KVM support?
>>>
>>> The current proposal is to still have KVM support in 5.6, as well as
>>> ongoing support for stable kernels. If that's not enough, can you please
>>> explain your precise use case?
>>
>> Presumably there's no *technical* reason why the stable subset of v7
>> support couldn't be stripped down and brought back private to arch/arm
>> if somebody really wants and is willing to step up and look after it?
>
> There is no technical reason at all, just a maintenance effort.
>
> The main killer is the whole MMU code, which I'm butchering with NV,
> and that I suspect Will will also turn upside down with his stuff.
> Not to mention the hypercall interface that will need a complete overhaul.
>
> If we wanted to decouple the two, we'd need to make the MMU code, the
> hypercalls, arm.c and a number of other bits private to 32bit.
Right, the prospective kvm-arm maintainer's gameplan would essentially
be an equivalent "move virt/kvm/arm to arch/arm/kvm" patch, but then
ripping out all the Armv8 and GICv3 gubbins instead. Yes, there would
then be lots of *similar* code to start with, but it would only diverge
further as v8 architecture development continues independently.
Anyway, I just thought it seemed worth saying out loud, to reassure
folks that a realistic middle-ground between "yay bye!" and "oh no the
end of the world!" does exist, namely "someone else's problem" :)
Robin.
^ permalink raw reply
* [PATCH] hwmon: (w83627ehf) Fix crash seen with W83627DHG-P
From: Guenter Roeck @ 2020-02-20 14:37 UTC (permalink / raw)
To: Hardware Monitoring
Cc: Jean Delvare, Guenter Roeck, Meelis Roos, Dr . David Alan Gilbert
Loading the driver on a system with W83627DHG-P crashes as follows.
w83627ehf: Found W83627DHG-P chip at 0x290
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 0 PID: 604 Comm: sensors Not tainted 5.6.0-rc2-00055-gca7e1fd1026c #29
Hardware name: /D425KT, BIOS MWPNT10N.86A.0132.2013.0726.1534 07/26/2013
RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
Code: [... ]
RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
Call Trace:
? cp_new_stat+0x12d/0x160
hwmon_attr_show_string+0x37/0x70 [hwmon]
dev_attr_show+0x14/0x50
sysfs_kf_seq_show+0xb5/0x1b0
seq_read+0xcf/0x460
vfs_read+0x9b/0x150
ksys_read+0x5f/0xe0
do_syscall_64+0x48/0x190
entry_SYSCALL_64_after_hwframe+0x44/0xa9
...
Temperature labels are not always present. Adjust sysfs attribute
visibility accordingly.
Reported-by: Meelis Roos <mroos@linux.ee>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Dr. David Alan Gilbert <linux@treblig.org>
Fixes: 266cd5835947 ("hwmon: (w83627ehf) convert to with_info interface")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/hwmon/w83627ehf.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index 7ffadc2da57b..5a5120121e50 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -1346,8 +1346,13 @@ w83627ehf_is_visible(const void *drvdata, enum hwmon_sensor_types type,
/* channel 0.., name 1.. */
if (!(data->have_temp & (1 << channel)))
return 0;
- if (attr == hwmon_temp_input || attr == hwmon_temp_label)
+ if (attr == hwmon_temp_input)
return 0444;
+ if (attr == hwmon_temp_label) {
+ if (data->temp_label)
+ return 0444;
+ return 0;
+ }
if (channel == 2 && data->temp3_val_only)
return 0;
if (attr == hwmon_temp_max) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 03/10] ASoC: tegra: add Tegra210 based DMIC driver
From: Jon Hunter @ 2020-02-20 14:36 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-4-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital MIC (DMIC) Controller is used to interface with Pulse Density
> Modulation (PDM) input devices. The DMIC controller implements a converter
> to convert PDM signals to Pulse Code Modulation (PCM) signals. From signal
> flow perspective, the DMIC can be viewed as a PDM receiver.
>
> This patch registers DMIC component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DMIC interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DMIC devices can be enabled in the DT via
> "nvidia,tegra210-dmic" compatible string. This driver can be used for
> Tegra186 and Tegra194 chips as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 1/4] ci: remove unnecessary dependency on Linux headers
From: Aaron Conole @ 2020-02-20 14:37 UTC (permalink / raw)
To: David Marchand; +Cc: thomas, dev, Michael Santana
In-Reply-To: <20200219194131.29417-2-david.marchand@redhat.com>
David Marchand <david.marchand@redhat.com> writes:
> Following removal of kmod compilation, we don't need to install
> linux-headers anymore.
>
> Fixes: ea860973592b ("ci: remove redundant configs disabling kmods")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 2/4] ci: fix Travis config warnings
From: Aaron Conole @ 2020-02-20 14:36 UTC (permalink / raw)
To: David Marchand; +Cc: thomas, dev, Michael Santana
In-Reply-To: <20200219194131.29417-3-david.marchand@redhat.com>
David Marchand <david.marchand@redhat.com> writes:
> Reading https://config.travis-ci.com/ and using
> https://config.travis-ci.com/explore to check changes, we can cleanup
> some warnings reported by the config validation options in Travis.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
Echoing what Thomas wrote, please include the issues warnings.
^ permalink raw reply
* Re: [PATCH v3 03/10] ASoC: tegra: add Tegra210 based DMIC driver
From: Jon Hunter @ 2020-02-20 14:36 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-4-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital MIC (DMIC) Controller is used to interface with Pulse Density
> Modulation (PDM) input devices. The DMIC controller implements a converter
> to convert PDM signals to Pulse Code Modulation (PCM) signals. From signal
> flow perspective, the DMIC can be viewed as a PDM receiver.
>
> This patch registers DMIC component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DMIC interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DMIC devices can be enabled in the DT via
> "nvidia,tegra210-dmic" compatible string. This driver can be used for
> Tegra186 and Tegra194 chips as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v7 04/24] mm: Move readahead nr_pages check into read_pages
From: Zi Yan @ 2020-02-20 14:36 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200219210103.32400-5-willy@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
On 19 Feb 2020, at 16:00, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Simplify the callers by moving the check for nr_pages and the BUG_ON
> into read_pages().
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> mm/readahead.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 61b15b6b9e72..9fcd4e32b62d 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -119,6 +119,9 @@ static void read_pages(struct address_space *mapping, struct file *filp,
> struct blk_plug plug;
> unsigned page_idx;
>
> + if (!nr_pages)
> + return;
> +
> blk_start_plug(&plug);
>
> if (mapping->a_ops->readpages) {
> @@ -138,6 +141,8 @@ static void read_pages(struct address_space *mapping, struct file *filp,
>
> out:
> blk_finish_plug(&plug);
> +
> + BUG_ON(!list_empty(pages));
> }
>
> /*
> @@ -180,8 +185,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * contiguous pages before continuing with the next
> * batch.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> + read_pages(mapping, filp, &page_pool, nr_pages,
> gfp_mask);
> nr_pages = 0;
> continue;
> @@ -202,9 +206,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * uptodate then the caller will launch readpage again, and
> * will then handle the error.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> - BUG_ON(!list_empty(&page_pool));
> + read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> }
>
> /*
> --
> 2.25.0
Looks good to me. Thanks.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply
* [PATCH] trace-cmd: Add output to show "make test"
From: Steven Rostedt @ 2020-02-20 14:36 UTC (permalink / raw)
To: Linux Trace Devel
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
The unit tests are made with "make test". In order to let developers know of
this option, have it displayed when just "make" is used.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 60cd1570..a3facaa9 100644
--- a/Makefile
+++ b/Makefile
@@ -364,6 +364,7 @@ $(obj)/lib/traceevent/plugins/trace_python_dir: force
show_gui_make:
@echo "Note: to build the gui, type \"make gui\""
@echo " to build man pages, type \"make doc\""
+ @echo " to build unit tests, type \"make test\""
PHONY += show_gui_make
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 03/10] ASoC: tegra: add Tegra210 based DMIC driver
From: Jon Hunter @ 2020-02-20 14:36 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-4-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital MIC (DMIC) Controller is used to interface with Pulse Density
> Modulation (PDM) input devices. The DMIC controller implements a converter
> to convert PDM signals to Pulse Code Modulation (PCM) signals. From signal
> flow perspective, the DMIC can be viewed as a PDM receiver.
>
> This patch registers DMIC component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DMIC interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DMIC devices can be enabled in the DT via
> "nvidia,tegra210-dmic" compatible string. This driver can be used for
> Tegra186 and Tegra194 chips as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 4/5] sched/pelt: Add a new runnable average signal
From: Vincent Guittot @ 2020-02-20 14:36 UTC (permalink / raw)
To: Valentin Schneider
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel, Phil Auld,
Parth Shah, Hillf Danton
In-Reply-To: <9fe822fc-c311-2b97-ae14-b9269dd99f1e@arm.com>
On Wed, 19 Feb 2020 at 21:10, Valentin Schneider
<valentin.schneider@arm.com> wrote:
>
> On 19/02/2020 12:55, Vincent Guittot wrote:
> > @@ -740,8 +740,10 @@ void init_entity_runnable_average(struct sched_entity *se)
> > * Group entities are initialized with zero load to reflect the fact that
> > * nothing has been attached to the task group yet.
> > */
> > - if (entity_is_task(se))
> > + if (entity_is_task(se)) {
> > + sa->runnable_avg = SCHED_CAPACITY_SCALE;
>
> So this is a comment that's more related to patch 5, but the relevant bit is
> here. I'm thinking this initialization might be too aggressive wrt load
> balance. This will also give different results between symmetric vs
> asymmetric topologies - a single fork() will make a LITTLE CPU group (at the
> base domain level) overloaded straight away. That won't happen for bigs or on
> symmetric topologies because
>
> // group_is_overloaded()
> sgs->group_capacity * imbalance_pct) < (sgs->group_runnable * 100)
>
> will be false - it would take more than one task for that to happen (due to
> the imbalance_pct).
>
> So maybe what we want here instead is to mimic what he have for utilization,
> i.e. initialize to half the spare capacity of the local CPU. IOW,
> conceptually something like this:
>
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 99249a2484b4..762717092235 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -740,10 +740,8 @@ void init_entity_runnable_average(struct sched_entity *se)
> * Group entities are initialized with zero load to reflect the fact that
> * nothing has been attached to the task group yet.
> */
> - if (entity_is_task(se)) {
> - sa->runnable_avg = SCHED_CAPACITY_SCALE;
> + if (entity_is_task(se))
> sa->load_avg = scale_load_down(se->load.weight);
> - }
>
> /* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */
> }
> @@ -796,6 +794,8 @@ void post_init_entity_util_avg(struct task_struct *p)
> }
> }
>
> + sa->runnable_avg = sa->util_avg;
> +
> if (p->sched_class != &fair_sched_class) {
> /*
> * For !fair tasks do:
> ---
>
> The current approach has the merit of giving some sort of hint to the LB
> that there is a bunch of new tasks that it could spread out, but I fear it
> is too aggressive.
I agree that setting by default to SCHED_CAPACITY_SCALE is too much
for little core.
The problem for little core can be fixed by using the cpu capacity instead
@@ -796,6 +794,8 @@ void post_init_entity_util_avg(struct task_struct *p)
}
}
+ sa->runnable_avg = cpu_scale;
+
if (p->sched_class != &fair_sched_class) {
/*
* For !fair tasks do:
>
> > sa->load_avg = scale_load_down(se->load.weight);
> > + }
> >
> > /* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */
> > }
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 04/24] mm: Move readahead nr_pages check into read_pages
From: Zi Yan @ 2020-02-20 14:36 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200219210103.32400-5-willy@infradead.org>
On 19 Feb 2020, at 16:00, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Simplify the callers by moving the check for nr_pages and the BUG_ON
> into read_pages().
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> mm/readahead.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 61b15b6b9e72..9fcd4e32b62d 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -119,6 +119,9 @@ static void read_pages(struct address_space *mapping, struct file *filp,
> struct blk_plug plug;
> unsigned page_idx;
>
> + if (!nr_pages)
> + return;
> +
> blk_start_plug(&plug);
>
> if (mapping->a_ops->readpages) {
> @@ -138,6 +141,8 @@ static void read_pages(struct address_space *mapping, struct file *filp,
>
> out:
> blk_finish_plug(&plug);
> +
> + BUG_ON(!list_empty(pages));
> }
>
> /*
> @@ -180,8 +185,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * contiguous pages before continuing with the next
> * batch.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> + read_pages(mapping, filp, &page_pool, nr_pages,
> gfp_mask);
> nr_pages = 0;
> continue;
> @@ -202,9 +206,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * uptodate then the caller will launch readpage again, and
> * will then handle the error.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> - BUG_ON(!list_empty(&page_pool));
> + read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> }
>
> /*
> --
> 2.25.0
Looks good to me. Thanks.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan Zi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: OpenPGP digital signature
Url : http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20200220/419c5d42/attachment-0001.bin
^ permalink raw reply
* [Cluster-devel] [PATCH v7 04/24] mm: Move readahead nr_pages check into read_pages
From: Zi Yan @ 2020-02-20 14:36 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200219210103.32400-5-willy@infradead.org>
On 19 Feb 2020, at 16:00, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Simplify the callers by moving the check for nr_pages and the BUG_ON
> into read_pages().
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> mm/readahead.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 61b15b6b9e72..9fcd4e32b62d 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -119,6 +119,9 @@ static void read_pages(struct address_space *mapping, struct file *filp,
> struct blk_plug plug;
> unsigned page_idx;
>
> + if (!nr_pages)
> + return;
> +
> blk_start_plug(&plug);
>
> if (mapping->a_ops->readpages) {
> @@ -138,6 +141,8 @@ static void read_pages(struct address_space *mapping, struct file *filp,
>
> out:
> blk_finish_plug(&plug);
> +
> + BUG_ON(!list_empty(pages));
> }
>
> /*
> @@ -180,8 +185,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * contiguous pages before continuing with the next
> * batch.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> + read_pages(mapping, filp, &page_pool, nr_pages,
> gfp_mask);
> nr_pages = 0;
> continue;
> @@ -202,9 +206,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * uptodate then the caller will launch readpage again, and
> * will then handle the error.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> - BUG_ON(!list_empty(&page_pool));
> + read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> }
>
> /*
> --
> 2.25.0
Looks good to me. Thanks.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan Zi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20200220/419c5d42/attachment.sig>
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 3/4] ci: use an explicit list of Travis jobs
From: Aaron Conole @ 2020-02-20 14:35 UTC (permalink / raw)
To: David Marchand; +Cc: thomas, dev, Michael Santana
In-Reply-To: <20200219194131.29417-4-david.marchand@redhat.com>
David Marchand <david.marchand@redhat.com> writes:
> Maintaining the .travis.yml requires some knowledge of how Travis
> computes the jobs list (combination of os: arch: compiler: etc...).
> Let's switch to an explicit list to find all jobs at a glance.
>
> To enhance readability, jobs have been sorted per arch/compiler with
> comments to isolate blocks.
>
> Setting required_packages for aarch64 native jobs is unnecessary,
> the global addons: values are the same.
>
> This commit does not change the jobs list (21 jobs in total).
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 4/4] ci: reorganise Travis jobs
From: Aaron Conole @ 2020-02-20 14:35 UTC (permalink / raw)
To: David Marchand; +Cc: Thomas Monjalon, dev, Michael Santana, Bruce Richardson
In-Reply-To: <CAJFAV8wWC9Sxeebt+nKPz81h8pHd+fK2uQi16HCfjsA8LCzMtA@mail.gmail.com>
David Marchand <david.marchand@redhat.com> writes:
> On Thu, Feb 20, 2020 at 11:42 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> 19/02/2020 22:39, Aaron Conole:
>> > David Marchand <david.marchand@redhat.com> writes:
>> >
>> > > Let's prune the jobs list to limit the amount of time spent by the robot
>> > > in Travis.
>> > >
>> > > Since meson enables automatically the relevant components, there is not
>> > > much gain in testing with extra_packages vs required_packages only.
>> > >
>> > > For a given arch/compiler/env combination, compilation is first tested
>> > > in all jobs that run tests or build the docs or run the ABI checks.
>> > > In the same context, for jobs that accumulates running tests, building
>> > > the docs etc..., those steps are independent and can be split to save
>> > > some cpu on Travis.
>> > >
>> > > With this, we go down from 21 to 15 jobs.
>> > >
>> > > Note: this patch requires a flush of the existing caches in Travis.
>> > >
>> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
>> > > ---
>> >
>> > In general, I think the idea with required vs. extra was to have a build
>> > that did the minimum required, and one that did all the packages (to
>> > allow a minimum vs. full DPDK).
>> >
>> > At least, that's from
>> > http://mails.dpdk.org/archives/dev/2019-January/124007.html
>>
>> I think the benefit of a minimum build is to have a quick report,
>> and easy to setup.
>
> Yes, Travis serves as a first gate when submitting patches.
> But since Travis is best effort/free, we can't have a full coverage.
>
>
>> > Not sure if that's still something anyone cares about.
>>
>> Given that Travis knows how to satisfy the dependencies,
>> and that we must wait for all jobs to finish,
>> I don't see any benefit of a minimal setup.
>
> This minimal setup also tests that dpdk dependencies are correct.
> If a change makes something rely on libX and libX is in the packages
> always installed in Travis, the missing dependency would not get
> caught.
>
> But here, this adds too many jobs.
>
> UNH, Intel and other CIs should step in and fill this kind of gap.
Okay, makes sense to me. Are one of these CI providers offering to
cover this?
Also,
Acked-by: Aaron Conole <aconole@redhat.com>
>
> --
> David Marchand
^ permalink raw reply
* RE: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
From: Chris Paterson @ 2020-02-20 14:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Michal Hocko, Rik van Riel, Catalin Marinas,
Santosh Shilimkar, Dave Chinner, Russell King - ARM Linux admin,
Linux Kernel Mailing List, Linux-MM, Yafang Shao,
Geert Uytterhoeven, Al Viro, cip-dev@lists.cip-project.org,
Johannes Weiner, linux-fsdevel, kernel-team@fb.com,
Kishon Vijay Abraham I, Linus Torvalds, Andrew Morton,
Roman Gushchin
In-Reply-To: <CAK8P3a3Za8dthPE7czQs+rK+xUq+ZZC4Sbj8QF5YjXvtfzop4Q@mail.gmail.com>
Hello,
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: 16 February 2020 20:38
>
> On Sun, Feb 16, 2020 at 8:54 PM Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> >
> > Hello Arnd, Geert,
> >
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 16 February 2020 09:45
> > > To: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Hi Arnd,
> > >
> > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann <arnd@arndb.de>
> > > wrote:
> > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split
> (even
> > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one
> above
> > > > > the 32-bit physical limit.
> >
> > Yep. One example is r8a7743-iwg20m.dtsi.
>
> This one has 2x512MB, with half above the 4GiB limit. This means it needs
> LPAE to address high physical addresses (which is fine), but it does not need
> highmem if one uses an appropriate CONFIG_VMSPLIT_* option.
>
> > > > Good to know. I think there are several other chips that have dual-
> channel
> > > > DDR3 and thus /can/ support this configuration, but this rarely happens.
> > > > Are you aware of commercial products that use a 4GB configuration,
> aside
> > > from
> > > > the reference board?
> >
> > iWave Systems make a range of SOM modules using the RZ/G1 SoCs.
> > I believe there are options for some of these to use 4 GB, although 1 or 2
> GB is
> > used in the boards we've upstreamed support for.
> >
> > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1,
> > but I'm not sure of the details.
>
> Both iWave and Emtrion only seem to list boards with 2GB or less on their
> websites today (with up to 15 year availability). My guess is that they had
> the same problem as everyone else in finding the right memory chips in
> the required quantities and/or long-term availability. iWave lists "By default
> 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory
> expansion support." on some boards, but that doesn't mean they ever
> shipped a 4GB configuration.
I probably should have been clearer before - I actually have a couple of iWave RZ/G1M SOM modules with 4GB DDR on them.
However I've never booted them nor do I know what the memory mapping is.
Kind regards, Chris
>
> Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
From: Chris Paterson @ 2020-02-20 14:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Russell King - ARM Linux admin,
Linus Torvalds, Michal Hocko, Rik van Riel, Catalin Marinas,
kernel-team@fb.com, Dave Chinner, Linux Kernel Mailing List,
Linux-MM, Yafang Shao, Al Viro, Johannes Weiner, linux-fsdevel,
Andrew Morton, Roman Gushchin, Linux ARM, Kishon Vijay Abraham I,
Santosh Shilimkar, cip-dev@lists.cip-project.org
In-Reply-To: <CAK8P3a3Za8dthPE7czQs+rK+xUq+ZZC4Sbj8QF5YjXvtfzop4Q@mail.gmail.com>
Hello,
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: 16 February 2020 20:38
>
> On Sun, Feb 16, 2020 at 8:54 PM Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> >
> > Hello Arnd, Geert,
> >
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 16 February 2020 09:45
> > > To: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Hi Arnd,
> > >
> > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann <arnd@arndb.de>
> > > wrote:
> > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split
> (even
> > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one
> above
> > > > > the 32-bit physical limit.
> >
> > Yep. One example is r8a7743-iwg20m.dtsi.
>
> This one has 2x512MB, with half above the 4GiB limit. This means it needs
> LPAE to address high physical addresses (which is fine), but it does not need
> highmem if one uses an appropriate CONFIG_VMSPLIT_* option.
>
> > > > Good to know. I think there are several other chips that have dual-
> channel
> > > > DDR3 and thus /can/ support this configuration, but this rarely happens.
> > > > Are you aware of commercial products that use a 4GB configuration,
> aside
> > > from
> > > > the reference board?
> >
> > iWave Systems make a range of SOM modules using the RZ/G1 SoCs.
> > I believe there are options for some of these to use 4 GB, although 1 or 2
> GB is
> > used in the boards we've upstreamed support for.
> >
> > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1,
> > but I'm not sure of the details.
>
> Both iWave and Emtrion only seem to list boards with 2GB or less on their
> websites today (with up to 15 year availability). My guess is that they had
> the same problem as everyone else in finding the right memory chips in
> the required quantities and/or long-term availability. iWave lists "By default
> 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory
> expansion support." on some boards, but that doesn't mean they ever
> shipped a 4GB configuration.
I probably should have been clearer before - I actually have a couple of iWave RZ/G1M SOM modules with 4GB DDR on them.
However I've never booted them nor do I know what the memory mapping is.
Kind regards, Chris
>
> Arnd
^ permalink raw reply
* Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: Eric Blake @ 2020-02-20 14:33 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <0b884ddcd0ac3a3c0b8cdd9d09c74566ac107c9a.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> Subcluster allocation in qcow2 is implemented by extending the
> existing L2 table entries and adding additional information to
> indicate the allocation status of each subcluster.
>
> This patch documents the changes to the qcow2 format and how they
> affect the calculation of the L2 cache size.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> @@ -437,7 +445,7 @@ cannot be relaxed without an incompatible layout change).
> Given an offset into the virtual disk, the offset into the image file can be
> obtained as follows:
>
> - l2_entries = (cluster_size / sizeof(uint64_t))
> + l2_entries = (cluster_size / sizeof(uint64_t)) [*]
>
> l2_index = (offset / cluster_size) % l2_entries
> l1_index = (offset / cluster_size) / l2_entries
> @@ -447,6 +455,8 @@ obtained as follows:
>
> return cluster_offset + (offset % cluster_size)
>
> + [*] this changes if Extended L2 Entries are enabled, see next section
> +The size of an extended L2 entry is 128 bits so the number of entries per table
> +is calculated using this formula:
> +
> + l2_entries = (cluster_size / (2 * sizeof(uint64_t)))
Is it worth unifying these statements by writing:
l2_entries = (cluster_size / ((1 + extended_l2) * sizeof(uint64_t)))
or is that too confusing?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH v1] MAINTAINERS: Sort entries in database for TI VPE/CAL
From: Benoit Parrot @ 2020-02-20 14:38 UTC (permalink / raw)
To: Andy Shevchenko, Mauro Carvalho Chehab
Cc: linux-media, linux-kernel, Linus Torvalds
In-Reply-To: <20200128145828.74161-1-andriy.shevchenko@linux.intel.com>
Mauro,
Can you pick up this patch?
There is already been at least 3 other similar patches posted in the last
month.
Thanks,
Benoit
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote on Tue [2020-Jan-28 16:58:28 +0200]:
> Run parse-maintainers.pl and choose TI VPE/CAL record. Fix it accordingly.
>
> Note, this is urgent fix, without which parse-maintainers.pl throws
> an exception:
>
> Odd non-pattern line ' Documentation/devicetree/bindings/media/ti,cal.yaml
> ' for 'TI VPE/CAL DRIVERS' at scripts/parse-maintainers.pl line 147, <$file> line 16770.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> MAINTAINERS | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9fbe2a19b8a3..f04b1c6508fe 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16761,12 +16761,12 @@ F: sound/soc/codecs/twl4030*
> TI VPE/CAL DRIVERS
> M: Benoit Parrot <bparrot@ti.com>
> L: linux-media@vger.kernel.org
> +S: Maintained
> W: http://linuxtv.org/
> Q: http://patchwork.linuxtv.org/project/linux-media/list/
> -S: Maintained
> -F: drivers/media/platform/ti-vpe/
> +F: Documentation/devicetree/bindings/media/ti,cal.yaml
> F: Documentation/devicetree/bindings/media/ti,vpe.yaml
> - Documentation/devicetree/bindings/media/ti,cal.yaml
> +F: drivers/media/platform/ti-vpe/
>
> TI WILINK WIRELESS DRIVERS
> L: linux-wireless@vger.kernel.org
> --
> 2.24.1
>
^ permalink raw reply
* [MPTCP] [PATCH v3 6/6] mptcp: send acks when moving skbs to mptcp receive queue
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]
This isn't strictly required, however, without this we will
punish flows that don't do bluk transmits as they will lag
behind in their window updates sent to peer.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
include/net/tcp.h | 1 +
net/ipv4/tcp.c | 2 +-
net/mptcp/protocol.c | 3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index a5ea27df3c2b..454ecab0df8b 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -650,6 +650,7 @@ static inline int tcp_bound_to_half_wnd(struct tcp_sock *tp, int pktsize)
/* tcp.c */
void tcp_get_info(struct sock *, struct tcp_info *);
+void tcp_cleanup_rbuf(struct sock *sk, int copied);
/* Read 'sendfile()'-style from a TCP socket */
int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1b685485a5b5..62362885a518 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1517,7 +1517,7 @@ static int tcp_peek_sndq(struct sock *sk, struct msghdr *msg, int len)
* calculation of whether or not we must ACK for the sake of
* a window update.
*/
-static void tcp_cleanup_rbuf(struct sock *sk, int copied)
+void tcp_cleanup_rbuf(struct sock *sk, int copied)
{
struct tcp_sock *tp = tcp_sk(sk);
bool time_to_ack = false;
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 02aba8b31f1f..93963bf3f9fe 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -773,6 +773,9 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
more_data_avail = mptcp_subflow_data_available(ssk);
} while (more_data_avail);
+ if (moved > 0)
+ tcp_cleanup_rbuf(ssk, moved);
+
release_sock(ssk);
} while (!done);
--
2.24.1
^ permalink raw reply related
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.