From: Stephen Hemminger
Date: Wed, 26 Jul 2017 16:40:19 -0700
> The next group of patches aims to reduce the driver memory footprint
> by reducing the size of the per-device receive and send buffers, and
> the per-channel receive completion queue.
Sorry Stephen, I have to draw the line with thos
Hi Roberto,
[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[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/Roberto-Sassu/ima-measure-digest
Hi Roberto,
[auto build test ERROR on integrity/next]
[also build test ERROR on v4.13-rc2 next-20170726]
[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/Roberto-Sassu/ima-measure-digest-lists
Hi Roberto,
[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[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/Roberto-Sassu/ima-measure-digest
On 27-07-17, 02:05, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add a description of the cpuinfo_cur_freq policy attribute in sysfs
> to the cpufreq documentation under Documentation/admin-guide/pm/ as
> it is missing after commit 2a0e49279850 (cpufreq: User/admin
> documentation updat
Hi Prarit,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc2]
[cannot apply to next-20170726]
[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/Prarit-Bhargava/printk
Hi Egil,
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Egil-Hjelmeland/net-dsa-lan9303-unicast-offload-fdb-mdb-STP/20170727-074246
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce
From: Rafael J. Wysocki
Add a description of the cpuinfo_cur_freq policy attribute in sysfs
to the cpufreq documentation under Documentation/admin-guide/pm/ as
it is missing after commit 2a0e49279850 (cpufreq: User/admin
documentation update and consolidation) that overlooked it.
Fixes: 2a0e4927
Latency improvement related to NAPI conversion.
If all packets are processed from receive ring then need
to signal host.
Signed-off-by: Stephen Hemminger
---
drivers/net/hyperv/netvsc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/
The internal API was passing struct hv_page_buffer **
when only simple struct hv_page_buffer * was necessary
for passing an array.
Signed-off-by: Stephen Hemminger
---
drivers/net/hyperv/hyperv_net.h | 2 +-
drivers/net/hyperv/netvsc.c | 21 ++---
drivers/net/hyperv/netv
This includes a bunch of fixups for issues reported by
lockdep.
* ethtool routines can assume RTNL
* send is done with RCU lock (and BH disable)
* avoid refetching internal device struct (netvsc)
instead pass it as a parameter.
Signed-off-by: Stephen Hemminger
---
drivers/net/hyper
The error and normal case got swapped.
Signed-off-by: Stephen Hemminger
---
drivers/net/hyperv/netvsc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 262486ce8e2a..f1eaf675d2e9 100644
--- a/drivers/
No longer needed, now all managed by transparent VF logic.
Signed-off-by: Stephen Hemminger
---
tools/hv/bondvf.sh | 255 -
1 file changed, 255 deletions(-)
delete mode 100755 tools/hv/bondvf.sh
diff --git a/tools/hv/bondvf.sh b/tools/hv/bond
This patch implements transparent fail over from synthetic NIC to
SR-IOV virtual function NIC in Hyper-V environment. It is a better
alternative to using bonding as is done now. Instead, the receive and
transmit fail over is done internally inside the driver.
Using bonding driver has lots of issue
The default value of send and receive buffer area for host DMA
is much larger than it needs to be. Experimentation shows that
4M receive and 1M send is sufficient.
Make the size a module parameter so that it can be adjusted
as needed for testing or special needs.
Signed-off-by: Stephen Hemminger
Add some background documentation on netvsc device options
and limitations.
Signed-off-by: Stephen Hemminger
---
Documentation/networking/netvsc.txt | 50 +
MAINTAINERS | 1 +
2 files changed, 51 insertions(+)
create mode 100644 Docum
Optimize how receive completion ring are managed.
* Allocate only as many slots as needed for all buffers from host
* Allocate before setting up sub channel for better error detection
* Don't need to keep copy of initial receive section message
* Precompute the watermark for when receiv
Using %p to print pointer to packet meta-data doesn't give any
good info, and exposes kernel memory offsets.
Signed-off-by: Stephen Hemminger
---
drivers/net/hyperv/netvsc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv
This series has updates for Hyper-V network driver.
The first four patches are just minor fixes.
The next group of patches aims to reduce the driver memory footprint
by reducing the size of the per-device receive and send buffers, and
the per-channel receive completion queue.
The biggest change i
Hi Roberto,
[cc'ing tpmdd-devel]
On Tue, 2017-07-25 at 17:44 +0200, Roberto Sassu wrote:
> This patch set applies on top of kernel v4.13-rc2.
>
> IMA, for each file matching policy rules, calculates a digest, creates
> a new entry in the measurement list and extends a TPM PCR with the digest
> o
> Good. Just one question about process. Could I have posted my work
> as a RFC? To get one round of initial feedback before chopping into
> small patch requests. As well as indicating where I am heading. Or is
> that just waste of human bandwidth?
Depends. Post 100 RFC patches, i won't look at th
Den 26. juli 2017 22:07, skrev David Miller:
From: Andrew Lunn
Date: Wed, 26 Jul 2017 19:52:24 +0200
So I really want to group the patches into only a few series in order
to not spend months on the process.
I strongly agree with Vivien here. Good patches get accepted in about
3 days. You sho
From: Andrew Lunn
Date: Wed, 26 Jul 2017 19:52:24 +0200
>> > So I really want to group the patches into only a few series in order
>> > to not spend months on the process.
>
> I strongly agree with Vivien here. Good patches get accepted in about
> 3 days. You should expect feedback within a day
> > So I really want to group the patches into only a few series in order
> > to not spend months on the process.
I strongly agree with Vivien here. Good patches get accepted in about
3 days. You should expect feedback within a day or two. That allows
you to have fast cycle times for getting patch
Hi Egil
> +/* This function will wait a while until mask & reg == value */
> +/* Otherwise, return timeout */
> +static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno,
> + int mask, char value)
> +{
> + int i;
> +
> + for (i = 0; i < 0x1000; i++) {
> +
Hi Egil
> +/* forward special tagged packets from port 0 to port 1 *or* port 2 */
> +static int lan9303_setup_tagging(struct lan9303 *chip)
> +{
> + int ret;
Blank line please.
> + /* enable defining the destination port via special VLAN tagging
> + * for port 0
> + */
> +
On Tue, Jul 25, 2017 at 06:15:49PM +0200, Egil Hjelmeland wrote:
> Allowing per-port access to Switch Engine Broadcast Throttling Register
Hi Egil
In general, we are against using sysfs. If there is a generic
mechanism, that applies for all sorts of network interfaces, it should
be used instead o
On Tue, Jul 25, 2017 at 06:15:47PM +0200, Egil Hjelmeland wrote:
> This makes the driver react to device tree "fixed-link" declaration
> on CPU port.
>
> - turn off autonegotiation
> - force speed 10 or 100 mb/s
> - force duplex mode
>
> Signed-off-by: Egil Hjelmeland
> ---
> drivers/net/dsa/la
On Tue, Jul 25, 2017 at 06:15:45PM +0200, Egil Hjelmeland wrote:
> For some mysterious reason enable switch fabric port 0 TX fails to
> work, when the TX has previous been disabled. Resolved by not
> disable/enable switch fabric port 0 at startup. Port 1 and 2 are
> still disabled in early init.
>
On Tue, Jul 25, 2017 at 06:15:44PM +0200, Egil Hjelmeland wrote:
> Fixes after testing on actual HW:
>
> - lan9303_mdio_write()/_read() must multiply register number
> by 4 to get offset
>
> - Indirect access (PMI) to phy register only work in I2C mode. In
> MDIO mode phy registers must be ac
On Wed, Jul 26, 2017 at 04:44:08PM +0200, Michal Hocko wrote:
> On Wed 26-07-17 16:24:34, Michal Hocko wrote:
> [...]
> > Or if you prefer I can post it separately?
>
> I've just tried to rebase relevant parts on top of the current mmotm
> tree and it needs some non-trivial updates. Would you mind
On 26. juli 2017 16:30, Vivien Didelot wrote:
Hi Egil,
Egil Hjelmeland writes:
I'd suggest you to split up this one commit in several *atomic* and easy
to review patches and send them separately as on thread named "net: dsa:
lan9303: fix MDIO interface" (also note that imperative is prefered
On Wed 26-07-17 16:24:34, Michal Hocko wrote:
[...]
> Or if you prefer I can post it separately?
I've just tried to rebase relevant parts on top of the current mmotm
tree and it needs some non-trivial updates. Would you mind if I post
those patches with you on CC? I really think that we shouldn't
Hi Egil,
Egil Hjelmeland writes:
>> I'd suggest you to split up this one commit in several *atomic* and easy
>> to review patches and send them separately as on thread named "net: dsa:
>> lan9303: fix MDIO interface" (also note that imperative is prefered for
>> subject lines, see: https://chris
On Wed 26-07-17 15:06:07, Roman Gushchin wrote:
> On Wed, Jul 26, 2017 at 03:56:22PM +0200, Michal Hocko wrote:
> > On Wed 26-07-17 14:27:15, Roman Gushchin wrote:
> > [...]
> > > @@ -656,13 +658,24 @@ static void mark_oom_victim(struct task_struct *tsk)
> > > struct mm_struct *mm = tsk->mm;
> >
On Wed, Jul 26, 2017 at 03:56:22PM +0200, Michal Hocko wrote:
> On Wed 26-07-17 14:27:15, Roman Gushchin wrote:
> [...]
> > @@ -656,13 +658,24 @@ static void mark_oom_victim(struct task_struct *tsk)
> > struct mm_struct *mm = tsk->mm;
> >
> > WARN_ON(oom_killer_disabled);
> > - /* OOM k
On Wed 26-07-17 14:27:15, Roman Gushchin wrote:
[...]
> @@ -656,13 +658,24 @@ static void mark_oom_victim(struct task_struct *tsk)
> struct mm_struct *mm = tsk->mm;
>
> WARN_ON(oom_killer_disabled);
> - /* OOM killer might race with memcg OOM */
> - if (test_and_set_tsk_thread
Update cgroups v2 docs.
Signed-off-by: Roman Gushchin
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Johannes Weiner
Cc: Tetsuo Handa
Cc: David Rientjes
Cc: Tejun Heo
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kv
Traditionally, the OOM killer is operating on a process level.
Under oom conditions, it finds a process with the highest oom score
and kills it.
This behavior doesn't suit well the system with many running
containers:
1) There is no fairness between containers. A small container with
few large pr
Introduce a per-memory-cgroup oom_priority setting: an integer number
within the [-1, 1] range, which defines the order in which
the OOM killer selects victim memory cgroups.
OOM killer prefers memory cgroups with larger priority if they are
populated with elegible tasks.
The oom_priority
First, separate tsk_is_oom_victim() and TIF_MEMDIE flag checks:
let the first one indicate that a task is killed by the OOM killer,
and the second one indicate that a task has an access to the memory
reserves (with a hope to eliminate it later).
Second, set TIF_MEMDIE to all threads of an OOM vict
On 25. juli 2017 21:15, Vivien Didelot wrote:
Hi Egil,
Egil Hjelmeland writes:
Fixes after testing on actual HW:
- lan9303_mdio_write()/_read() must multiply register number
by 4 to get offset
- Indirect access (PMI) to phy register only work in I2C mode. In
MDIO mode phy registers mu
42 matches
Mail list logo
