* [PATCH] ipvs: Remove unused variable ret from sync_thread_master()
From: Geert Uytterhoeven @ 2013-11-12 13:53 UTC (permalink / raw)
To: Peter Zijlstra, Oleg Nesterov, Ingo Molnar
Cc: netdev, linux-kernel, Geert Uytterhoeven
net/netfilter/ipvs/ip_vs_sync.c: In function 'sync_thread_master':
net/netfilter/ipvs/ip_vs_sync.c:1640:8: warning: unused variable 'ret' [-Wunused-variable]
Introduced by commit 35a2af94c7ce7130ca292c68b1d27fcfdb648f6b ("sched/wait:
Make the __wait_event*() interface more friendly")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
net/netfilter/ipvs/ip_vs_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index f63c2388f38d..d258125c4202 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -1637,7 +1637,7 @@ static int sync_thread_master(void *data)
continue;
}
while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
- int ret = __wait_event_interruptible(*sk_sleep(sk),
+ __wait_event_interruptible(*sk_sleep(sk),
sock_writeable(sk) ||
kthread_should_stop());
if (unlikely(kthread_should_stop()))
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC 04/10] drivers: reset: stih415: add softreset controller
From: srinivas.kandagatla @ 2013-11-12 13:52 UTC (permalink / raw)
To: linux-arm-kernel, netdev
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Russell King, Srinivas Kandagatla,
Stuart Menefy, Pavel Machek, Rafael J. Wysocki, Len Brown,
stephen.gallimore, Greg Kroah-Hartman, Giuseppe Cavallaro,
Grant Likely, devicetree, linux-doc, linux-kernel, kernel,
linux-pm
In-Reply-To: <1384264311-7308-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds softreset controller for STiH415 SOC, soft reset
controller is based on system configuration registers which are mapped
via regmap. This reset controller does not have any feedback or
acknowledgement. With this patch a new device "st,stih415-softreset" is
registered with system configuration registers based reset controller
that controls the softreset state of the hardware such as Ethernet, IRB.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
.../devicetree/bindings/reset/st,sti-softreset.txt | 45 ++++++++++++++++++++
arch/arm/boot/dts/stih415.dtsi | 5 ++
drivers/reset/sti/reset-stih415.c | 22 ++++++++++
.../dt-bindings/reset-controller/stih415-resets.h | 4 ++
4 files changed, 76 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reset/st,sti-softreset.txt
diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
new file mode 100644
index 0000000..b2df262
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
@@ -0,0 +1,45 @@
+STMicroelectronics STi family Sysconfig Peripheral SoftReset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"softreset" control bits found in the STi family SoC system configuration
+registers.
+
+The actual action taken when softreset is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-softreset"
+- #reset-cells: 1, see below
+
+example:
+
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the softreset device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+ ethernet0{
+ resets = <&softreset STIH415_ETH0_SOFTRESET>;
+ };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index 09379a6b..0c0776e 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -33,6 +33,11 @@
compatible = "st,stih415-powerdown";
};
+ softreset: softreset-controller {
+ #reset-cells = <1>;
+ compatible = "st,stih415-softreset";
+ };
+
syscfg_sbc: sbc-syscfg@fe600000{
compatible = "st,stih415-sbc-syscfg", "syscon";
reg = <0xfe600000 0xb4>;
diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
index 56c2146..fce5153 100644
--- a/drivers/reset/sti/reset-stih415.c
+++ b/drivers/reset/sti/reset-stih415.c
@@ -37,6 +37,10 @@ static const char stih415_lpm[] = "st,stih415-lpm-syscfg";
#define SYSCFG_336 0x90 /* Powerdown request USB/SATA/PCIe */
#define SYSSTAT_384 0x150 /* Powerdown status USB/SATA/PCIe */
+#define SYSCFG_166 0x108 /* Softreset Ethernet 0 */
+#define SYSCFG_31 0x7c /* Softreset Ethernet 1 */
+#define LPM_SYSCFG_1 0x4 /* Softreset IRB */
+
static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_EMISS_POWERDOWN] = STIH415_PDN_FRONT(0),
[STIH415_NAND_POWERDOWN] = STIH415_PDN_FRONT(1),
@@ -49,15 +53,33 @@ static const struct syscfg_reset_channel_data stih415_powerdowns[] = {
[STIH415_PCIE_POWERDOWN] = STIH415_PDN_REAR(5, 8),
};
+static const struct syscfg_reset_channel_data stih415_softresets[] = {
+ [STIH415_ETH0_SOFTRESET] = _SYSCFG_RST_CH_NO_ACK(stih415_front,
+ SYSCFG_166, 0),
+ [STIH415_ETH1_SOFTRESET] = _SYSCFG_RST_CH_NO_ACK(stih415_sbc,
+ SYSCFG_31, 0),
+ [STIH415_IRB_SOFTRESET] = _SYSCFG_RST_CH_NO_ACK(stih415_lpm,
+ LPM_SYSCFG_1, 6),
+};
+
static struct syscfg_reset_controller_data stih415_powerdown_controller = {
.wait_for_ack = true,
.nr_channels = ARRAY_SIZE(stih415_powerdowns),
.channels = stih415_powerdowns,
};
+static struct syscfg_reset_controller_data stih415_softreset_controller = {
+ .wait_for_ack = false,
+ .active_low = true,
+ .nr_channels = ARRAY_SIZE(stih415_softresets),
+ .channels = stih415_softresets,
+};
+
static struct of_device_id stih415_reset_match[] = {
{ .compatible = "st,stih415-powerdown",
.data = &stih415_powerdown_controller, },
+ { .compatible = "st,stih415-softreset",
+ .data = &stih415_softreset_controller, },
{},
};
diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
index 2d54e68..825ed41 100644
--- a/include/dt-bindings/reset-controller/stih415-resets.h
+++ b/include/dt-bindings/reset-controller/stih415-resets.h
@@ -16,4 +16,8 @@
#define STIH415_SATA1_POWERDOWN 7
#define STIH415_PCIE_POWERDOWN 8
+#define STIH415_ETH0_SOFTRESET 0
+#define STIH415_ETH1_SOFTRESET 1
+#define STIH415_IRB_SOFTRESET 2
+
#endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
--
1.7.6.5
^ permalink raw reply related
* Re: IPv6: Blackhole route support partial ?
From: Hannes Frederic Sowa @ 2013-11-12 13:54 UTC (permalink / raw)
To: Kamala R; +Cc: davem, linux-kernel, netdev
In-Reply-To: <CAP8BHkG6=KuU9K7=sGsZftMDe58eTYByRu2DZ+j+KNqcfsOfAA@mail.gmail.com>
On Tue, Nov 12, 2013 at 04:39:10PM +0530, Kamala R wrote:
> Hi,
>
> Sure, here it is.
>
> --- linux-3.12/net/ipv6/route.c.orig 2013-11-12 16:23:46.000000000 +0530
> +++ linux-3.12/net/ipv6/route.c 2013-11-12 16:30:51.000000000 +0530
> @@ -1570,9 +1570,13 @@ int ip6_route_add(struct fib6_config *cf
> switch (cfg->fc_type) {
> case RTN_BLACKHOLE:
> rt->dst.error = -EINVAL;
> + rt->dst.input = dst_discard;
> + rt->dst.discard = dst_discard;
> break;
> case RTN_PROHIBIT:
> rt->dst.error = -EACCES;
> + rt->dst.input = ip6_pkt_prohibit;
> + rt->dst.output = ip6_pkt_prohibit_out;
> break;
> case RTN_THROW:
> rt->dst.error = -EAGAIN;
>
> Is this ok ?
I woud move all the initialization of the function pointer into the
switch-case. You could merge the case RTN_THROW with the default one by just
using a ternary statement to initialize dst.error.
Your patch must be well-formed to get included into the
kernel. For that you should base your patch ontop net-next
or net, write a proper commit message and send the git
format-patch generated patch to this list. Here some hints:
<https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/Documentation/SubmittingPatches>
You can check if your formatting is correct by using scripts/checkpatch
--strict.
Let me know if there are any problems with that.
Thank you,
Hannes
^ permalink raw reply
* [PATCH RFC 10/10] ARM: STi: Add STiH416 ethernet support.
From: srinivas.kandagatla @ 2013-11-12 13:53 UTC (permalink / raw)
To: linux-arm-kernel, netdev
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Russell King, Srinivas Kandagatla,
Stuart Menefy, Pavel Machek, Rafael J. Wysocki, Len Brown,
stephen.gallimore, Greg Kroah-Hartman, Giuseppe Cavallaro,
Grant Likely, devicetree, linux-doc, linux-kernel, kernel,
linux-pm
In-Reply-To: <1384264311-7308-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch adds support to STiH416 SOC, which has two ethernet
snps,dwmac controllers version 3.710. With this patch B2000 and B2020
boards can boot with ethernet in MII and RGMII modes.
Tested on both B2020 and B2000.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
arch/arm/boot/dts/stih416-clock.dtsi | 14 ++++
arch/arm/boot/dts/stih416-pinctrl.dtsi | 106 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/stih416.dtsi | 58 +++++++++++++++++
3 files changed, 178 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/stih416-clock.dtsi b/arch/arm/boot/dts/stih416-clock.dtsi
index 7026bf1..a6942c7 100644
--- a/arch/arm/boot/dts/stih416-clock.dtsi
+++ b/arch/arm/boot/dts/stih416-clock.dtsi
@@ -37,5 +37,19 @@
clock-frequency = <100000000>;
clock-output-names = "CLK_S_ICN_REG_0";
};
+
+ CLK_S_GMAC0_PHY: clockgenA1@7 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "CLK_S_GMAC0_PHY";
+ };
+
+ CLK_S_ETH1_PHY: clockgenA0@7 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "CLK_S_ETH1_PHY";
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index 0f246c9..216754f 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -97,6 +97,59 @@
};
};
};
+
+ gmac1 {
+ pinctrl_mii1: mii1 {
+ st,pins {
+ txd0 = <&PIO0 0 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd1 = <&PIO0 1 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd2 = <&PIO0 2 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txd3 = <&PIO0 3 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txer = <&PIO0 4 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txen = <&PIO0 5 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+ txclk = <&PIO0 6 ALT1 IN NICLK 0 CLK_A>;
+ col = <&PIO0 7 ALT1 IN BYPASS 1000>;
+
+ mdio = <&PIO1 0 ALT1 OUT BYPASS 1500>;
+ mdc = <&PIO1 1 ALT1 OUT NICLK 0 CLK_A>;
+ crs = <&PIO1 2 ALT1 IN BYPASS 1000>;
+ mdint = <&PIO1 3 ALT1 IN BYPASS 0>;
+ rxd0 = <&PIO1 4 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd1 = <&PIO1 5 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd2 = <&PIO1 6 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxd3 = <&PIO1 7 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+
+ rxdv = <&PIO2 0 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rx_er = <&PIO2 1 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+ rxclk = <&PIO2 2 ALT1 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO2 3 ALT1 OUT NICLK 0 CLK_A>;
+ };
+ };
+ pinctrl_rgmii1: rgmii1-0 {
+ st,pins {
+ txd0 = <&PIO0 0 ALT1 OUT DE_IO 500 CLK_A>;
+ txd1 = <&PIO0 1 ALT1 OUT DE_IO 500 CLK_A>;
+ txd2 = <&PIO0 2 ALT1 OUT DE_IO 500 CLK_A>;
+ txd3 = <&PIO0 3 ALT1 OUT DE_IO 500 CLK_A>;
+ txen = <&PIO0 5 ALT1 OUT DE_IO 0 CLK_A>;
+ txclk = <&PIO0 6 ALT1 IN NICLK 0 CLK_A>;
+
+ mdio = <&PIO1 0 ALT1 OUT BYPASS 0>;
+ mdc = <&PIO1 1 ALT1 OUT NICLK 0 CLK_A>;
+ rxd0 = <&PIO1 4 ALT1 IN DE_IO 500 CLK_A>;
+ rxd1 = <&PIO1 5 ALT1 IN DE_IO 500 CLK_A>;
+ rxd2 = <&PIO1 6 ALT1 IN DE_IO 500 CLK_A>;
+ rxd3 = <&PIO1 7 ALT1 IN DE_IO 500 CLK_A>;
+
+ rxdv = <&PIO2 0 ALT1 IN DE_IO 500 CLK_A>;
+ rxclk = <&PIO2 2 ALT1 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO2 3 ALT4 OUT NICLK 0 CLK_B>;
+
+ clk125= <&PIO3 7 ALT4 IN NICLK 0 CLK_A>;
+ };
+ };
+ };
+
};
pin-controller-front {
@@ -230,6 +283,59 @@
};
};
};
+
+ gmac0 {
+ pinctrl_mii0: mii0 {
+ st,pins {
+ mdint = <&PIO13 6 ALT2 IN BYPASS 0>;
+ txen = <&PIO13 7 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd0 = <&PIO14 0 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd1 = <&PIO14 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ txd2 = <&PIO14 2 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+ txd3 = <&PIO14 3 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+
+ txclk = <&PIO15 0 ALT2 IN NICLK 0 CLK_A>;
+ txer = <&PIO15 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+ crs = <&PIO15 2 ALT2 IN BYPASS 1000>;
+ col = <&PIO15 3 ALT2 IN BYPASS 1000>;
+ mdio= <&PIO15 4 ALT2 OUT BYPASS 1500>;
+ mdc = <&PIO15 5 ALT2 OUT NICLK 0 CLK_B>;
+
+ rxd0 = <&PIO16 0 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd1 = <&PIO16 1 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd2 = <&PIO16 2 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxd3 = <&PIO16 3 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxdv = <&PIO15 6 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rx_er = <&PIO15 7 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+ rxclk = <&PIO17 0 ALT2 IN NICLK 0 CLK_A>;
+ phyclk = <&PIO13 5 ALT2 OUT NICLK 0 CLK_B>;
+ };
+ };
+
+ pinctrl_rgmii0: rgmii0 {
+ st,pins {
+ phyclk = <&PIO13 5 ALT4 OUT NICLK 0 CLK_B>;
+ txen = <&PIO13 7 ALT2 OUT DE_IO 0 CLK_A>;
+ txd0 = <&PIO14 0 ALT2 OUT DE_IO 500 CLK_A>;
+ txd1 = <&PIO14 1 ALT2 OUT DE_IO 500 CLK_A>;
+ txd2 = <&PIO14 2 ALT2 OUT DE_IO 500 CLK_B>;
+ txd3 = <&PIO14 3 ALT2 OUT DE_IO 500 CLK_B>;
+ txclk = <&PIO15 0 ALT2 IN NICLK 0 CLK_A>;
+
+ mdio = <&PIO15 4 ALT2 OUT BYPASS 0>;
+ mdc = <&PIO15 5 ALT2 OUT NICLK 0 CLK_B>;
+
+ rxdv = <&PIO15 6 ALT2 IN DE_IO 500 CLK_A>;
+ rxd0 =<&PIO16 0 ALT2 IN DE_IO 500 CLK_A>;
+ rxd1 =<&PIO16 1 ALT2 IN DE_IO 500 CLK_A>;
+ rxd2 =<&PIO16 2 ALT2 IN DE_IO 500 CLK_A>;
+ rxd3 =<&PIO16 3 ALT2 IN DE_IO 500 CLK_A>;
+ rxclk =<&PIO17 0 ALT2 IN NICLK 0 CLK_A>;
+
+ clk125=<&PIO17 6 ALT1 IN NICLK 0 CLK_A>;
+ };
+ };
+ };
};
pin-controller-fvdp-fe {
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index a3831a3..bf052fb 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -103,5 +103,63 @@
pinctrl-0 = <&pinctrl_sbc_serial1>;
clocks = <&CLK_SYSIN>;
};
+
+ ethernet0: ethernet0{
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+ compatible = "st,stih416-dwmac";
+ reg = <0x8bc 0x4>;
+ st,syscon = <&syscfg_rear>;
+ resets = <&softreset STIH416_ETH0_SOFTRESET>;
+ ranges;
+
+ dwmac@fe810000 {
+ device_type = "network";
+ compatible = "snps,dwmac", "snps,dwmac-3.710";
+ status = "disabled";
+ reg = <0xfe810000 0x8000>;
+
+ interrupts = <0 133 0>, <0 134 0>, <0 135 0>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+
+ snps,pbl = <32>;
+ snps,mixed-burst;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mii0>;
+ clock-names = "stmmaceth";
+ clocks = <&CLK_S_GMAC0_PHY>;
+ };
+ };
+
+ ethernet1: ethernet1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+ compatible = "st,stih416-dwmac";
+ reg = <0x7f0 0x4>;
+ st,syscon = <&syscfg_sbc>;
+ resets = <&softreset STIH416_ETH1_SOFTRESET>;
+ ranges;
+
+ dwmac@fef08000 {
+ device_type = "network";
+ compatible = "snps,dwmac", "snps,dwmac-3.710";
+ status = "disabled";
+ reg = <0xfef08000 0x8000>;
+ interrupts = <0 136 0>, <0 137 0>, <0 138 0>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+
+ snps,pbl = <32>;
+ snps,mixed-burst;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mii1>;
+ clock-names = "stmmaceth";
+ clocks = <&CLK_S_ETH1_PHY>;
+ };
+ };
+
};
};
--
1.7.6.5
^ permalink raw reply related
* Re: [Fwd: Re: [PATCH v2 2/2] x86: add prefetching to do_csum]
From: Neil Horman @ 2013-11-12 13:59 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, Dave Jones, linux-kernel, sebastien.dugue,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Eric Dumazet
In-Reply-To: <1384220542.4771.23.camel@joe-AO722>
On Mon, Nov 11, 2013 at 05:42:22PM -0800, Joe Perches wrote:
> Hi again Neil.
>
> Forwarding on to netdev with a concern as to how often
> do_csum is used via csum_partial for very short headers
> and what impact any prefetch would have there.
>
> Also, what changed in your test environment?
>
> Why are the new values 5+% higher cycles/byte than the
> previous values?
>
Hmm, thank you, I didn't notice the increase. I think I rebooted my system and
failed to reset my irq affinity to avoid the processor I was testing on. Let me
rerun.
Neil
> And here is the new table reformatted:
>
> len set iterations Readahead cachelines vs cycles/byte
> 1 2 3 4 6 10 20
> 1500B 64MB 1000000 1.4342 1.4300 1.4350 1.4350 1.4396 1.4315 1.4555
> 1500B 128MB 1000000 1.4312 1.4346 1.4271 1.4284 1.4376 1.4318 1.4431
> 1500B 256MB 1000000 1.4309 1.4254 1.4316 1.4308 1.4418 1.4304 1.4367
> 1500B 512MB 1000000 1.4534 1.4516 1.4523 1.4563 1.4554 1.4644 1.4590
> 9000B 64MB 1000000 0.8921 0.8924 0.8932 0.8949 0.8952 0.8939 0.8985
> 9000B 128MB 1000000 0.8841 0.8856 0.8845 0.8854 0.8861 0.8879 0.8861
> 9000B 256MB 1000000 0.8806 0.8821 0.8813 0.8833 0.8814 0.8827 0.8895
> 9000B 512MB 1000000 0.8838 0.8852 0.8841 0.8865 0.8846 0.8901 0.8865
> 64KB 64MB 1000000 0.8132 0.8136 0.8132 0.8150 0.8147 0.8149 0.8147
> 64KB 128MB 1000000 0.8013 0.8014 0.8013 0.8020 0.8041 0.8015 0.8033
> 64KB 256MB 1000000 0.7956 0.7959 0.7956 0.7976 0.7981 0.7967 0.7973
> 64KB 512MB 1000000 0.7934 0.7932 0.7937 0.7951 0.7954 0.7943 0.7948
>
> -------- Forwarded Message --------
> From: Neil Horman <nhorman@tuxdriver.com>
> To: Joe Perches <joe@perches.com>
> Cc: Dave Jones <davej@redhat.com>, linux-kernel@vger.kernel.org,
> sebastien.dugue@bull.net, Thomas Gleixner <tglx@linutronix.de>, Ingo
> Molnar <mingo@redhat.com>, H. Peter Anvin <hpa@zytor.com>,
> x86@kernel.org
> Subject: Re: [PATCH v2 2/2] x86: add prefetching to do_csum
>
> On Fri, Nov 08, 2013 at 12:29:07PM -0800, Joe Perches wrote:
> > On Fri, 2013-11-08 at 15:14 -0500, Neil Horman wrote:
> > > On Fri, Nov 08, 2013 at 11:33:13AM -0800, Joe Perches wrote:
> > > > On Fri, 2013-11-08 at 14:01 -0500, Neil Horman wrote:
> > > > > On Wed, Nov 06, 2013 at 09:19:23AM -0800, Joe Perches wrote:
> > > > > > On Wed, 2013-11-06 at 10:54 -0500, Neil Horman wrote:
> > > > > > > On Wed, Nov 06, 2013 at 10:34:29AM -0500, Dave Jones wrote:
> > > > > > > > On Wed, Nov 06, 2013 at 10:23:19AM -0500, Neil Horman wrote:
> > > > > > > > > do_csum was identified via perf recently as a hot spot when doing
> > > > > > > > > receive on ip over infiniband workloads. After alot of testing and
> > > > > > > > > ideas, we found the best optimization available to us currently is to
> > > > > > > > > prefetch the entire data buffer prior to doing the checksum
> > > > > > []
> > > > > > > I'll fix this up and send a v3, but I'll give it a day in case there are more
> > > > > > > comments first.
> > > > > >
> > > > > > Perhaps a reduction in prefetch loop count helps.
> > > > > >
> > > > > > Was capping the amount prefetched and letting the
> > > > > > hardware prefetch also tested?
> > > > > >
> > > > > > prefetch_lines(buff, min(len, cache_line_size() * 8u));
> > > > > >
> > > > >
> > > > > Just tested this out:
> > > >
> > > > Thanks.
> > > >
> > > > Reformatting the table so it's a bit more
> > > > readable/comparable for me:
> > > >
> > > > len SetSz Loops cycles/byte
> > > > limited unlimited
> > > > 1500B 64MB 1M 1.3442 1.3605
> > > > 1500B 128MB 1M 1.3410 1.3542
> > > > 1500B 256MB 1M 1.3536 1.3710
> > > > 1500B 512MB 1M 1.3463 1.3536
> > > > 9000B 64MB 1M 0.8522 0.8504
> > > > 9000B 128MB 1M 0.8528 0.8536
> > > > 9000B 256MB 1M 0.8532 0.8520
> > > > 9000B 512MB 1M 0.8527 0.8525
> > > > 64KB 64MB 1M 0.7686 0.7683
> > > > 64KB 128MB 1M 0.7695 0.7686
> > > > 64KB 256MB 1M 0.7699 0.7708
> > > > 64KB 512MB 1M 0.7799 0.7694
> > > >
> > > > This data appears to show some value
> > > > in capping for 1500b lengths and noise
> > > > for shorter and longer lengths.
> > > >
> > > > Any idea what the actual distribution of
> > > > do_csum lengths is under various loads?
> > > >
> > > I don't have any hard data no, sorry.
> >
> > I think you should before you implement this.
> > You might find extremely short lengths.
> >
> > > I'll cap the prefetch at 1500B for now, since it
> > > doesn't seem to hurt or help beyond that
> >
> > The table data has a max prefetch of
> > 8 * boot_cpu_data.x86_cache_alignment so
> > I believe it's always less than 1500 but
> > perhaps 4 might be slightly better still.
> >
>
>
> So, you appear to be correct, I reran my test set with different prefetch
> ceilings and got the results below. There are some cases in which there is a
> performance gain, but the gain is small, and occurs at different spots depending
> on the input buffer size (though most peak gains appear around 2 cache lines).
> I'm guessing it takes about 2 prefetches before hardware prefetching catches up,
> at which point we're just spending time issuing instructions that get discarded.
> Given the small prefetch limit, and the limited gains (which may also change on
> different hardware), I think we should probably just drop the prefetch idea
> entirely, and perhaps just take the perf patch so that we can revisit this area
> when hardware that supports the avx extensions and/or adcx/adox becomes
> available.
>
> Ingo, does that seem reasonable to you?
> Neil
>
>
>
> 1 cache line:
> len | set | iterations | cycles/byte
> ========|=======|===============|=============
> 1500B | 64MB | 1000000 | 1.434190
> 1500B | 128MB | 1000000 | 1.431216
> 1500B | 256MB | 1000000 | 1.430888
> 1500B | 512MB | 1000000 | 1.453422
> 9000B | 64MB | 1000000 | 0.892055
> 9000B | 128MB | 1000000 | 0.884050
> 9000B | 256MB | 1000000 | 0.880551
> 9000B | 512MB | 1000000 | 0.883848
> 64KB | 64MB | 1000000 | 0.813187
> 64KB | 128MB | 1000000 | 0.801326
> 64KB | 256MB | 1000000 | 0.795643
> 64KB | 512MB | 1000000 | 0.793400
>
>
> 2 cache lines:
> len | set | iterations | cycles/byte
> ========|=======|===============|=============
> 1500B | 64MB | 1000000 | 1.430030
> 1500B | 128MB | 1000000 | 1.434589
> 1500B | 256MB | 1000000 | 1.425430
> 1500B | 512MB | 1000000 | 1.451570
> 9000B | 64MB | 1000000 | 0.892369
> 9000B | 128MB | 1000000 | 0.885577
> 9000B | 256MB | 1000000 | 0.882091
> 9000B | 512MB | 1000000 | 0.885201
> 64KB | 64MB | 1000000 | 0.813629
> 64KB | 128MB | 1000000 | 0.801377
> 64KB | 256MB | 1000000 | 0.795861
> 64KB | 512MB | 1000000 | 0.793242
>
> 3 cache lines:
> len | set | iterations | cycles/byte
> ========|=======|===============|=============
> 1500B | 64MB | 1000000 | 1.435048
> 1500B | 128MB | 1000000 | 1.427103
> 1500B | 256MB | 1000000 | 1.431558
> 1500B | 512MB | 1000000 | 1.452250
> 9000B | 64MB | 1000000 | 0.893162
> 9000B | 128MB | 1000000 | 0.884488
> 9000B | 256MB | 1000000 | 0.881314
> 9000B | 512MB | 1000000 | 0.884060
> 64KB | 64MB | 1000000 | 0.813185
> 64KB | 128MB | 1000000 | 0.801280
> 64KB | 256MB | 1000000 | 0.795554
> 64KB | 512MB | 1000000 | 0.793670
>
> 4 cache lines:
> len | set | iterations | cycles/byte
> ========|=======|===============|=============
> 1500B | 64MB | 1000000 | 1.435013
> 1500B | 128MB | 1000000 | 1.428434
> 1500B | 256MB | 1000000 | 1.430780
> 1500B | 512MB | 1000000 | 1.456285
> 9000B | 64MB | 1000000 | 0.894877
> 9000B | 128MB | 1000000 | 0.885387
> 9000B | 256MB | 1000000 | 0.883293
> 9000B | 512MB | 1000000 | 0.886462
> 64KB | 64MB | 1000000 | 0.815036
> 64KB | 128MB | 1000000 | 0.801962
> 64KB | 256MB | 1000000 | 0.797618
> 64KB | 512MB | 1000000 | 0.795138
>
> 6 cache lines:
> len | set | iterations | cycles/byte
> ========|=======|===============|=============
> 1500B | 64MB | 1000000 | 1.439609
> 1500B | 128MB | 1000000 | 1.437569
> 1500B | 256MB | 1000000 | 1.441776
> 1500B | 512MB | 1000000 | 1.455362
> 9000B | 64MB | 1000000 | 0.895242
> 9000B | 128MB | 1000000 | 0.886149
> 9000B | 256MB | 1000000 | 0.881375
> 9000B | 512MB | 1000000 | 0.884610
> 64KB | 64MB | 1000000 | 0.814658
> 64KB | 128MB | 1000000 | 0.804124
> 64KB | 256MB | 1000000 | 0.798143
> 64KB | 512MB | 1000000 | 0.795377
>
> 10 cache lines:
> len | set | iterations | cycles/byte
> ========|=======|===============|=============
> 1500B | 64MB | 1000000 | 1.431512
> 1500B | 128MB | 1000000 | 1.431805
> 1500B | 256MB | 1000000 | 1.430388
> 1500B | 512MB | 1000000 | 1.464370
> 9000B | 64MB | 1000000 | 0.893922
> 9000B | 128MB | 1000000 | 0.887852
> 9000B | 256MB | 1000000 | 0.882711
> 9000B | 512MB | 1000000 | 0.890067
> 64KB | 64MB | 1000000 | 0.814890
> 64KB | 128MB | 1000000 | 0.801470
> 64KB | 256MB | 1000000 | 0.796658
> 64KB | 512MB | 1000000 | 0.794266
>
> 20 cache lines:
> len | set | iterations | cycles/byte
> ========|=======|===============|=============
> 1500B | 64MB | 1000000 | 1.455539
> 1500B | 128MB | 1000000 | 1.443117
> 1500B | 256MB | 1000000 | 1.436739
> 1500B | 512MB | 1000000 | 1.458973
> 9000B | 64MB | 1000000 | 0.898470
> 9000B | 128MB | 1000000 | 0.886110
> 9000B | 256MB | 1000000 | 0.889549
> 9000B | 512MB | 1000000 | 0.886547
> 64KB | 64MB | 1000000 | 0.814665
> 64KB | 128MB | 1000000 | 0.803252
> 64KB | 256MB | 1000000 | 0.797268
> 64KB | 512MB | 1000000 | 0.794830
>
>
>
>
^ permalink raw reply
* Re: [PATCH RFC 07/10] PM / wakeup : Introduce device_child_may_wakeup
From: srinivas kandagatla @ 2013-11-12 14:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-arm-kernel, netdev, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Rob Landley, Russell King,
Stuart Menefy, Pavel Machek, Len Brown, stephen.gallimore,
Greg Kroah-Hartman, Giuseppe Cavallaro, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, linux-pm
In-Reply-To: <4093206.klj58BXQv3@vostro.rjw.lan>
On 12/11/13 14:20, Rafael J. Wysocki wrote:
>>
>> > +/* callback for device_child_may_wakeup */
>> > +static int __device_child_may_wakeup(struct device *dev, void *c)
>> > +{
>> > + return device_may_wakeup(dev);
>> > +}
> This doesn't have anything to do with children in principle, so please call
> it differently. Something like device_may_wakeup_cb() would work for me (and
> then you may not need the comment even).
Thanks Rafael, I will fix this in next version.
>
> Thanks!
>
>> > +
>> > +/**
^ permalink raw reply
* Re: [PATCH] ipvs: Remove unused variable ret from sync_thread_master()
From: Peter Zijlstra @ 2013-11-12 14:13 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Oleg Nesterov, Ingo Molnar, netdev, linux-kernel
In-Reply-To: <1384264396-14550-1-git-send-email-geert@linux-m68k.org>
On Tue, Nov 12, 2013 at 02:53:16PM +0100, Geert Uytterhoeven wrote:
> net/netfilter/ipvs/ip_vs_sync.c: In function 'sync_thread_master':
> net/netfilter/ipvs/ip_vs_sync.c:1640:8: warning: unused variable 'ret' [-Wunused-variable]
>
> Introduced by commit 35a2af94c7ce7130ca292c68b1d27fcfdb648f6b ("sched/wait:
> Make the __wait_event*() interface more friendly")
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> net/netfilter/ipvs/ip_vs_sync.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
> index f63c2388f38d..d258125c4202 100644
> --- a/net/netfilter/ipvs/ip_vs_sync.c
> +++ b/net/netfilter/ipvs/ip_vs_sync.c
> @@ -1637,7 +1637,7 @@ static int sync_thread_master(void *data)
> continue;
> }
> while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
> - int ret = __wait_event_interruptible(*sk_sleep(sk),
So ideally there's be a comment here why we're using interruptible but
then ignore interruptions.
Julian said (
http://lkml.kernel.org/r/alpine.LFD.2.00.1310012245020.1782@ja.ssi.bg ):
" Yes, your patch looks ok to me. In the past
we used ssleep() but IPVS users were confused why
IPVS threads increase the load average. So, we
switched to _interruptible calls and later the socket
polling was added. "
So maybe add something like
/*
* (Ab)use interruptible sleep to avoid increasing
* the load avg.
*/
> + __wait_event_interruptible(*sk_sleep(sk),
> sock_writeable(sk) ||
> kthread_should_stop());
> if (unlikely(kthread_should_stop()))
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: TCP performance regression
From: Eric Dumazet @ 2013-11-12 14:16 UTC (permalink / raw)
To: Willy Tarreau; +Cc: David Laight, Sujith Manoharan, netdev, Dave Taht
In-Reply-To: <20131112074243.GA10318@1wt.eu>
On Tue, 2013-11-12 at 08:42 +0100, Willy Tarreau wrote:
> Well, it's not *that* large, 532 descriptors is 800 kB or 6.4 ms with
> 1500-bytes packets, and 273 microseconds for 64-byte packets. In fact
> it's not a slow interface, it's the systems it runs on which are
> generally not that fast. For example it is possible to saturate two
> gig ports at once on a single-core Armada370. But you need buffers
> large enough to compensate for the context switch time if you use
> multiple threads to send.
With GSO, each 1500-bytes packet might need 2 descriptors anyway (one
for the headers, one for the payload), so 532 descriptors only hold 400
kB or 3.2 ms ;)
If the NIC was supporting TSO, this would be another story, as a 64KB
packet could use only 3 descriptors.
^ permalink raw reply
* Re: [PATCH RFC 07/10] PM / wakeup : Introduce device_child_may_wakeup
From: Rafael J. Wysocki @ 2013-11-12 14:20 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: linux-arm-kernel, netdev, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Rob Landley, Russell King,
Stuart Menefy, Pavel Machek, Len Brown, stephen.gallimore,
Greg Kroah-Hartman, Giuseppe Cavallaro, Grant Likely, devicetree,
linux-doc, linux-kernel, kernel, linux-pm
In-Reply-To: <1384264377-7609-1-git-send-email-srinivas.kandagatla@st.com>
On Tuesday, November 12, 2013 01:52:57 PM srinivas.kandagatla@st.com wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> This patch introduces device_child_may_wakeup function, which will be
> useful for wrapper or SoC level driver power management code.
> Without this patch each driver has to write this same code to get the
> functionality.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> ---
> drivers/base/power/wakeup.c | 23 +++++++++++++++++++++++
> include/linux/pm_wakeup.h | 1 +
> 2 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index 2d56f41..270f000 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -342,6 +342,29 @@ int device_set_wakeup_enable(struct device *dev, bool enable)
> }
> EXPORT_SYMBOL_GPL(device_set_wakeup_enable);
>
> +/* callback for device_child_may_wakeup */
> +static int __device_child_may_wakeup(struct device *dev, void *c)
> +{
> + return device_may_wakeup(dev);
> +}
This doesn't have anything to do with children in principle, so please call
it differently. Something like device_may_wakeup_cb() would work for me (and
then you may not need the comment even).
Thanks!
> +
> +/**
> + * device_child_may_wakeup - Check if any of the child devices are wakeup
> + * sources.
> + * @dev: parent device to handle.
> + *
> + * Function to check if any of the children of a given parent are wakeup
> + * sources.
> + *
> + * This function will return true if any one of the children of given parent
> + * are wakeup sources, else it returns false.
> + */
> +bool device_child_may_wakeup(struct device *parent)
> +{
> + return device_for_each_child(parent, NULL, __device_child_may_wakeup);
> +}
> +EXPORT_SYMBOL_GPL(device_child_may_wakeup);
> +
> /*
> * The functions below use the observation that each wakeup event starts a
> * period in which the system should not be suspended. The moment this period
> diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
> index a0f7080..b376584 100644
> --- a/include/linux/pm_wakeup.h
> +++ b/include/linux/pm_wakeup.h
> @@ -93,6 +93,7 @@ extern int device_wakeup_disable(struct device *dev);
> extern void device_set_wakeup_capable(struct device *dev, bool capable);
> extern int device_init_wakeup(struct device *dev, bool val);
> extern int device_set_wakeup_enable(struct device *dev, bool enable);
> +bool device_child_may_wakeup(struct device *parent);
> extern void __pm_stay_awake(struct wakeup_source *ws);
> extern void pm_stay_awake(struct device *dev);
> extern void __pm_relax(struct wakeup_source *ws);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH net 1/2] tuntap: limit head length of skb allocated
From: Jason Wang @ 2013-11-12 14:21 UTC (permalink / raw)
To: davem, netdev, linux-kernel, mst, stefanha
In-Reply-To: <1384250577-20330-1-git-send-email-jasowang@redhat.com>
----- 原始邮件 -----
> We currently use hdr_len as a hint of head length which is advertised by
> guest. But when guest advertise a very big value, it can lead to an 64K+
> allocating of kmalloc() which has a very high possibility of failure when
> host
> memory is fragmented or under heavy stress. The huge hdr_len also reduce the
> effect of zerocopy or even disable if a gso skb is linearized in guest.
>
> To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of
> the
> head, which guarantees an order 0 allocation each time.
>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> The patch was needed for stable.
> ---
> drivers/net/tun.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 7cb105c..5537b65 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -954,6 +954,11 @@ static struct sk_buff *tun_alloc_skb(struct tun_file
> *tfile,
> struct sock *sk = tfile->socket.sk;
> struct sk_buff *skb;
> int err;
> + int good_linear = SKB_MAX_HEAD(prepad);
> +
> + /* Don't use huge linear part */
> + if (linear > good_linear)
> + linear = good_linear;
>
> /* Under a page? Don't bother with paged skb. */
> if (prepad + len < PAGE_SIZE || !linear)
> --
> 1.8.3.2
>
Looks like reduce the linear here will cause callers' iov_pages() under estimation.
Will send V2.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* RE: [PATCH] ipvs: Remove unused variable ret from sync_thread_master()
From: David Laight @ 2013-11-12 14:21 UTC (permalink / raw)
To: Peter Zijlstra, Geert Uytterhoeven
Cc: Oleg Nesterov, Ingo Molnar, netdev, linux-kernel
In-Reply-To: <20131112141314.GQ5056@laptop.programming.kicks-ass.net>
> > @@ -1637,7 +1637,7 @@ static int sync_thread_master(void *data)
> > continue;
> > }
> > while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
> > - int ret = __wait_event_interruptible(*sk_sleep(sk),
>
> So ideally there's be a comment here why we're using interruptible but
> then ignore interruptions.
>
> Julian said (
> http://lkml.kernel.org/r/alpine.LFD.2.00.1310012245020.1782@ja.ssi.bg ):
>
> " Yes, your patch looks ok to me. In the past
> we used ssleep() but IPVS users were confused why
> IPVS threads increase the load average. So, we
> switched to _interruptible calls and later the socket
> polling was added. "
I've done this in the past so that the code sleeps interruptibly
unless there is a signal pending - which would cause it to return
early.
/* Tell scheduler we are going to sleep... */
if (signal_pending(current))
/* We don't want waking immediately (again) */
sleep_state = TASK_UNINTERRUPTIBLE;
else
sleep_state = TASK_INTERRUPTIBLE;
set_current_state(sleep_state);
Shame there isn't a process flag to indicate that the process
will sleep uninterruptibly and that it doesn't matter.
So don't count to the load average and don't emit a warning
if it has been sleeping for a long time.
David
^ permalink raw reply
* Re: [PATCH] ipvs: Remove unused variable ret from sync_thread_master()
From: Peter Zijlstra @ 2013-11-12 14:31 UTC (permalink / raw)
To: David Laight
Cc: Geert Uytterhoeven, Oleg Nesterov, Ingo Molnar, netdev,
linux-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7405@saturn3.aculab.com>
On Tue, Nov 12, 2013 at 02:21:39PM -0000, David Laight wrote:
> > > @@ -1637,7 +1637,7 @@ static int sync_thread_master(void *data)
> > > continue;
> > > }
> > > while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
> > > - int ret = __wait_event_interruptible(*sk_sleep(sk),
> >
> > So ideally there's be a comment here why we're using interruptible but
> > then ignore interruptions.
> >
> > Julian said (
> > http://lkml.kernel.org/r/alpine.LFD.2.00.1310012245020.1782@ja.ssi.bg ):
> >
> > " Yes, your patch looks ok to me. In the past
> > we used ssleep() but IPVS users were confused why
> > IPVS threads increase the load average. So, we
> > switched to _interruptible calls and later the socket
> > polling was added. "
>
> I've done this in the past so that the code sleeps interruptibly
> unless there is a signal pending - which would cause it to return
> early.
>
> /* Tell scheduler we are going to sleep... */
> if (signal_pending(current))
> /* We don't want waking immediately (again) */
> sleep_state = TASK_UNINTERRUPTIBLE;
> else
> sleep_state = TASK_INTERRUPTIBLE;
> set_current_state(sleep_state);
If this is for kernel threads, I think you can wipe the pending state;
not entirely sure how signals interact with kthreads; Oleg will know.
^ permalink raw reply
* [PATCH -v2] ipvs: Remove unused variable ret from sync_thread_master()
From: Geert Uytterhoeven @ 2013-11-12 14:34 UTC (permalink / raw)
To: Peter Zijlstra, Oleg Nesterov, Ingo Molnar, Julian Anastasov
Cc: netdev, linux-kernel, Geert Uytterhoeven
net/netfilter/ipvs/ip_vs_sync.c: In function 'sync_thread_master':
net/netfilter/ipvs/ip_vs_sync.c:1640:8: warning: unused variable 'ret' [-Wunused-variable]
Commit 35a2af94c7ce7130ca292c68b1d27fcfdb648f6b ("sched/wait: Make the
__wait_event*() interface more friendly") changed how the interruption
state is returned. However, sync_thread_master() ignores this state,
now causing a compile warning.
According to Julian Anastasov <ja@ssi.bg>, this behavior is OK:
"Yes, your patch looks ok to me. In the past we used ssleep() but IPVS
users were confused why IPVS threads increase the load average. So, we
switched to _interruptible calls and later the socket polling was
added."
Document this, as requested by Peter Zijlstra, to avoid precious developers
disappearing in this pitfall in the future.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
v2: Document that sync_thread_master() ignores the interruption state,
net/netfilter/ipvs/ip_vs_sync.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index f63c2388f38d..db801263ee9f 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -1637,7 +1637,10 @@ static int sync_thread_master(void *data)
continue;
}
while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
- int ret = __wait_event_interruptible(*sk_sleep(sk),
+ /* (Ab)use interruptible sleep to avoid increasing
+ * the load avg.
+ */
+ __wait_event_interruptible(*sk_sleep(sk),
sock_writeable(sk) ||
kthread_should_stop());
if (unlikely(kthread_should_stop()))
--
1.7.9.5
^ permalink raw reply related
* [PATCH net] bonding: don't permit to use ARP monitoring in 802.3ad mode
From: Veaceslav Falico @ 2013-11-12 14:37 UTC (permalink / raw)
To: netdev; +Cc: Veaceslav Falico, Jay Vosburgh, Andy Gospodarek
Currently the ARP monitoring is not supported with 802.3ad, and it's
prohibited to use it via the module params.
However we still can set it afterwards via sysfs, cause we only check for
*LB modes there.
To fix this - add a check for 802.3ad mode in bonding_store_arp_interval.
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_sysfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index c29b836..e386d6b 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -587,8 +587,9 @@ static ssize_t bonding_store_arp_interval(struct device *d,
goto out;
}
if (bond->params.mode == BOND_MODE_ALB ||
- bond->params.mode == BOND_MODE_TLB) {
- pr_info("%s: ARP monitoring cannot be used with ALB/TLB. Only MII monitoring is supported on %s.\n",
+ bond->params.mode == BOND_MODE_TLB ||
+ bond->params.mode == BOND_MODE_8023AD) {
+ pr_info("%s: ARP monitoring cannot be used with ALB/TLB/802.3ad. Only MII monitoring is supported on %s.\n",
bond->dev->name, bond->dev->name);
ret = -EINVAL;
goto out;
--
1.8.4
^ permalink raw reply related
* [PATCH] tcp: tsq: restore minimal amount of queueing
From: Eric Dumazet @ 2013-11-12 14:39 UTC (permalink / raw)
To: Arnaud Ebalard, David Miller, Sujith Manoharan
Cc: Cong Wang, netdev, Felix Fietkau
In-Reply-To: <87y54u59zq.fsf@natisbad.org>
From: Eric Dumazet <edumazet@google.com>
After commit c9eeec26e32e ("tcp: TSQ can use a dynamic limit"), several
users reported throughput regressions, notably on mvneta and wifi
adapters.
802.11 AMPDU requires a fair amount of queueing to be effective.
This patch partially reverts the change done in tcp_write_xmit()
so that the minimal amount is sysctl_tcp_limit_output_bytes.
It also remove the use of this sysctl while building skb stored
in write queue, as TSO autosizing does the right thing anyway.
Users with well behaving NICS and correct qdisc (like sch_fq),
can then lower the default sysctl_tcp_limit_output_bytes value from
128KB to 8KB.
The new usage of sysctl_tcp_limit_output_bytes permits each driver
author to check how driver performs when/if the value is set
to a minimum of 4KB :
Normally, line rate for a single TCP flow should be possible,
but some drivers rely on timers to perform TX completion and
too long delays prevent reaching full throughput.
Fixes: c9eeec26e32e ("tcp: TSQ can use a dynamic limit")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Sujith Manoharan <sujith@msujith.org>
Reported-by: Arnaud Ebalard <arno@natisbad.org>
Cc: Felix Fietkau <nbd@openwrt.org>
---
Documentation/networking/ip-sysctl.txt | 3 ---
net/ipv4/tcp.c | 6 ------
net/ipv4/tcp_output.c | 6 +++++-
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index a46d785..7d8dc93 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -588,9 +588,6 @@ tcp_limit_output_bytes - INTEGER
typical pfifo_fast qdiscs.
tcp_limit_output_bytes limits the number of bytes on qdisc
or device to reduce artificial RTT/cwnd and reduce bufferbloat.
- Note: For GSO/TSO enabled flows, we try to have at least two
- packets in flight. Reducing tcp_limit_output_bytes might also
- reduce the size of individual GSO packet (64KB being the max)
Default: 131072
tcp_challenge_ack_limit - INTEGER
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 6e5617b..be5246e 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -806,12 +806,6 @@ static unsigned int tcp_xmit_size_goal(struct sock *sk, u32 mss_now,
xmit_size_goal = min_t(u32, gso_size,
sk->sk_gso_max_size - 1 - hlen);
- /* TSQ : try to have at least two segments in flight
- * (one in NIC TX ring, another in Qdisc)
- */
- xmit_size_goal = min_t(u32, xmit_size_goal,
- sysctl_tcp_limit_output_bytes >> 1);
-
xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal);
/* We try hard to avoid divides here */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index d46f214..9f0b338 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1875,8 +1875,12 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
* - better RTT estimation and ACK scheduling
* - faster recovery
* - high rates
+ * Alas, some drivers / subsystems require a fair amount
+ * of queued bytes to ensure line rate.
+ * One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max(skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = max(sysctl_tcp_limit_output_bytes,
+ sk->sk_pacing_rate >> 10);
if (atomic_read(&sk->sk_wmem_alloc) > limit) {
set_bit(TSQ_THROTTLED, &tp->tsq_flags);
^ permalink raw reply related
* RE: [PATCH] ipvs: Remove unused variable ret from sync_thread_master()
From: David Laight @ 2013-11-12 14:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Geert Uytterhoeven, Oleg Nesterov, Ingo Molnar, netdev,
linux-kernel
In-Reply-To: <20131112143152.GS5056@laptop.programming.kicks-ass.net>
> > I've done this in the past so that the code sleeps interruptibly
> > unless there is a signal pending - which would cause it to return
> > early.
> >
> > /* Tell scheduler we are going to sleep... */
> > if (signal_pending(current))
> > /* We don't want waking immediately (again) */
> > sleep_state = TASK_UNINTERRUPTIBLE;
> > else
> > sleep_state = TASK_INTERRUPTIBLE;
> > set_current_state(sleep_state);
>
> If this is for kernel threads, I think you can wipe the pending state;
> not entirely sure how signals interact with kthreads; Oleg will know.
I did take me a while to manage to use kthreads, and we probably still
have customers who insist on using pre 2.6.18 kernels!
(In which case the processes are children of a daemon that only
return to userspace in order to exit.)
We also need to send signals (to get the process out of blocking
socket calls), so I have to use force_sig() to get the signal noticed.
The other issue was tidyup - I had to find module_put_and_exit().
David
^ permalink raw reply
* Re:Answer back
From: lee hyuk @ 2013-11-12 10:52 UTC (permalink / raw)
I would like to discuss a very important crude oil project withyou,kindly
revert back to me if this is your valid email address forfurther
information.
Regards,
Lee
^ permalink raw reply
* Re: [PATCH] ipvs: Remove unused variable ret from sync_thread_master()
From: Peter Zijlstra @ 2013-11-12 14:52 UTC (permalink / raw)
To: David Laight
Cc: Geert Uytterhoeven, Oleg Nesterov, Ingo Molnar, netdev,
linux-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7405@saturn3.aculab.com>
On Tue, Nov 12, 2013 at 02:21:39PM -0000, David Laight wrote:
> Shame there isn't a process flag to indicate that the process
> will sleep uninterruptibly and that it doesn't matter.
> So don't count to the load average and don't emit a warning
> if it has been sleeping for a long time.
A process flag wouldn't work, because the task could block waiting for
actual work to complete in other sleeps.
However, we could do something like the below; which would allow us
writing things like:
(void)___wait_event(*sk_sleep(sk),
sock_writeable(sk) || kthread_should_stop(),
TASK_UNINTERRUPTIBLE | TASK_IDLE, 0, 0,
schedule());
Marking the one wait-for-more-work as TASK_IDLE such that it doesn't
contribute to the load avg.
---
fs/proc/array.c | 23 ++++++++++++-----------
include/linux/sched.h | 8 +++++---
include/trace/events/sched.h | 3 ++-
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 1bd2077187fd..da9a9c8b5bba 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -133,17 +133,18 @@ static inline void task_name(struct seq_file *m, struct task_struct *p)
* simple bit tests.
*/
static const char * const task_state_array[] = {
- "R (running)", /* 0 */
- "S (sleeping)", /* 1 */
- "D (disk sleep)", /* 2 */
- "T (stopped)", /* 4 */
- "t (tracing stop)", /* 8 */
- "Z (zombie)", /* 16 */
- "X (dead)", /* 32 */
- "x (dead)", /* 64 */
- "K (wakekill)", /* 128 */
- "W (waking)", /* 256 */
- "P (parked)", /* 512 */
+ "R (running)", /* 0 */
+ "S (sleeping)", /* 1 */
+ "D (disk sleep)", /* 2 */
+ "T (stopped)", /* 4 */
+ "t (tracing stop)", /* 8 */
+ "Z (zombie)", /* 16 */
+ "X (dead)", /* 32 */
+ "x (dead)", /* 64 */
+ "K (wakekill)", /* 128 */
+ "W (waking)", /* 256 */
+ "P (parked)", /* 512 */
+ "I (idle)", /* 1024 */
};
static inline const char *get_task_state(struct task_struct *tsk)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 045b0d227846..a4a9e80688d8 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -145,9 +145,10 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq);
#define TASK_WAKEKILL 128
#define TASK_WAKING 256
#define TASK_PARKED 512
-#define TASK_STATE_MAX 1024
+#define TASK_IDLE 1024
+#define TASK_STATE_MAX 2048
-#define TASK_STATE_TO_CHAR_STR "RSDTtZXxKWP"
+#define TASK_STATE_TO_CHAR_STR "RSDTtZXxKWPI"
extern char ___assert_task_state[1 - 2*!!(
sizeof(TASK_STATE_TO_CHAR_STR)-1 != ilog2(TASK_STATE_MAX)+1)];
@@ -173,7 +174,8 @@ extern char ___assert_task_state[1 - 2*!!(
((task->state & (__TASK_STOPPED | __TASK_TRACED)) != 0)
#define task_contributes_to_load(task) \
((task->state & TASK_UNINTERRUPTIBLE) != 0 && \
- (task->flags & PF_FROZEN) == 0)
+ (task->flags & PF_FROZEN) == 0 && \
+ (task->state & TASK_IDLE) == 0)
#define __set_task_state(tsk, state_value) \
do { (tsk)->state = (state_value); } while (0)
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 04c308413a5d..4553a2495c25 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -144,7 +144,8 @@ TRACE_EVENT(sched_switch,
__print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
{ 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" },
{ 16, "Z" }, { 32, "X" }, { 64, "x" },
- { 128, "K" }, { 256, "W" }, { 512, "P" }) : "R",
+ { 128, "K" }, { 256, "W" }, { 512, "P" },
+ { 1024, "I" }) : "R",
__entry->prev_state & TASK_STATE_MAX ? "+" : "",
__entry->next_comm, __entry->next_pid, __entry->next_prio)
);
^ permalink raw reply related
* Re: [PATCH] tcp: tsq: restore minimal amount of queueing
From: Sujith Manoharan @ 2013-11-12 15:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: Arnaud Ebalard, David Miller, Cong Wang, netdev, Felix Fietkau
In-Reply-To: <1384267141.28458.24.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> After commit c9eeec26e32e ("tcp: TSQ can use a dynamic limit"), several
> users reported throughput regressions, notably on mvneta and wifi
> adapters.
>
> 802.11 AMPDU requires a fair amount of queueing to be effective.
>
> This patch partially reverts the change done in tcp_write_xmit()
> so that the minimal amount is sysctl_tcp_limit_output_bytes.
>
> It also remove the use of this sysctl while building skb stored
> in write queue, as TSO autosizing does the right thing anyway.
>
> Users with well behaving NICS and correct qdisc (like sch_fq),
> can then lower the default sysctl_tcp_limit_output_bytes value from
> 128KB to 8KB.
>
> The new usage of sysctl_tcp_limit_output_bytes permits each driver
> author to check how driver performs when/if the value is set
> to a minimum of 4KB :
>
> Normally, line rate for a single TCP flow should be possible,
> but some drivers rely on timers to perform TX completion and
> too long delays prevent reaching full throughput.
I tested the patch with ath9k and performance with a 2-stream card is normal
again, about 195 Mbps in open air.
Thanks for the fix !
Also, I think this needs to be marked as a stable candidate, since 3.12 needs
this fix.
Sujith
^ permalink raw reply
* Re: [PATCH net] netlink: fix netlink_ack with large messages
From: Jiri Benc @ 2013-11-12 15:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Jamal Hadi Salim, David Miller, tgraf, netdev
In-Reply-To: <20131109180353.GA3715@localhost>
On Sat, 9 Nov 2013 19:03:53 +0100, Pablo Neira Ayuso wrote:
> On Sat, Nov 09, 2013 at 08:43:51AM -0500, Jamal Hadi Salim wrote:
> > for errors, we need to give the user something back. This has been the
> > behavior for 80 years now. Giving them a HUGE message
> > back is rediculuos(tm). Ive had enough of SCTP doing that.
> > We need to cap it - sort of what ICMP does.
> > ICMP caps at 64B; something like 128B is reasonable.
>
> Personally, I have only used the sequence number to correlate the
> original request with the ack reply, so I agree in that trimming it to
> some reasonable amount of bytes like ICMP is the way to go. I prefer
> if we select a large enough amount of bytes to avoid breaking backward
> compatibility, eg. 128KB, since I'm not sure what kind of handling
> others may have done of this.
Do you think capping at NLMSG_GOODSIZE would be too low? The allocation
won't fit into one page with NLMSG_GOODSIZE but I doubt we can go lower
than that. Alternatively, we can do some math to fully use the two
pages, like
NLMSG_GOODSIZE + min(PAGE_SIZE, 8192UL) - NLMSG_HDRLEN - NLMSG_ALIGN(sizeof(struct nlmsgerr))
(which I'm not sure is worth it).
Jiri
--
Jiri Benc
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Arnaud Ebalard @ 2013-11-12 15:34 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Cong Wang, edumazet, stable, linux-arm-kernel, netdev
In-Reply-To: <20131112100126.GB23981@1wt.eu>
Hi,
Willy Tarreau <w@1wt.eu> writes:
> On Tue, Nov 12, 2013 at 10:14:34AM +0100, Arnaud Ebalard wrote:
>> Tests for the rgression were done w/ scp, and were hence limited by the
>> crypto (16MB/s using arcfour128). But I also did some tests w/ a simple
>> wget for a file served by Apache *before* the regression and I never got
>> more than 60MB/s from what I recall. Can you beat that?
>
> Yes, I finally picked my mirabox out of my bag for a quick test. It boots
> off 3.10.0-rc7 and I totally saturate one port (stable 988 Mbps) with even
> a single TCP stream.
Thanks for the feedback. That's interesting. What are you using for your tests
(wget, ...)?
> With two systems, one directly connected (dockstar) and the other one via
> a switch, I get 2*650 Mbps (a single TCP stream is enough on each).
>
> I'll have to re-run some tests using a more up to date kernel, but that
> will probably not be today though.
Can you give a pre-3.11.7 kernel a try if you find the time? I started
working on RN102 during 3.10-rc cycle but do not remember if I did the
first preformance tests on 3.10 or 3.11. And if you find more time,
3.11.7 would be nice too ;-)
Cheers,
a+
^ permalink raw reply
* [PATCH] usbnet: fix status interrupt urb handling
From: Felix Fietkau @ 2013-11-12 15:34 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, dcbw-H+wXaHxf7aLQT0dZR+AlfA
Since commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf
"sierra_net: keep status interrupt URB active", sierra_net triggers
status interrupt polling before the net_device is opened (in order to
properly receive the sync message response).
To be able to receive further interrupts, the interrupt urb needs to be
re-submitted, so this patch removes the bogus check for netif_running().
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
---
drivers/net/usb/usbnet.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 90a429b..8494bb5 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -204,9 +204,6 @@ static void intr_complete (struct urb *urb)
break;
}
- if (!netif_running (dev->net))
- return;
^ permalink raw reply related
* Re: [PATCH net] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-12 15:46 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Ding Tianhong, Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131112113610.GB19702@redhat.com>
于 2013/11/12 19:36, Veaceslav Falico 写道:
> On Tue, Nov 12, 2013 at 07:25:24PM +0800, Ding Tianhong wrote:
>> I met a Bug when I add ip target with the wrong ip address:
>>
>> echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
>>
>> the wrong ip address will transfor to 245.245.245.244 and add
>> to the ip target success, it is uncorrect, so I add checks to avoid
>> adding wrong address.
>>
>> The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
>> the next check and will not add to ip target.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> drivers/net/bonding/bond_sysfs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Your mail client, apparently, transformed tabs into spaces, so the patch
> doesn't apply.
>
yes, the patch was made in net-next, I forget to make it in net, I'll
send it by office mail in office later.
Thanks.
Regards
Ding
>>
>> diff --git a/drivers/net/bonding/bond_sysfs.c
>> b/drivers/net/bonding/bond_sysfs.c
>> index 4838a97..5b7bf37 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -612,7 +612,7 @@ static ssize_t bonding_store_arp_targets(struct
>> device *d,
>> return restart_syscall();
>>
>> targets = bond->params.arp_targets;
>> - newtarget = in_aton(buf + 1);
>> + in4_pton(buf + 1, strlen(buf) - 1, (u8 *)&newtarget, -1, NULL);
>> /* look for adds */
>> if (buf[0] == '+') {
>> if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
>> --
>> 1.8.2.1
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: Alan Stern @ 2013-11-12 16:08 UTC (permalink / raw)
To: David Laight
Cc: Sarah Sharp, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73FF-CgBM+Bx2aUAnGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On Tue, 12 Nov 2013, David Laight wrote:
> > You're right. I do wish the spec had been written more clearly.
>
> I've read a lot of hardware specs in my time ...
>
> > > Reading it all again makes me think that a LINK trb is only
> > > allowed on the burst boundary (which might be 16k bytes).
> > > The only real way to implement that is to ensure that TD never
> > > contain LINK TRB.
> >
> > That's one way to do it. Or you could allow a Link TRB at an
> > intermediate MBP boundary.
>
> If all the fragments are larger than the MBP (assume 16k) then
> that would be relatively easy. However that is very dependant
> on the source of the data. It might be true for disk data, but
> is unlikely to be true for ethernet data.
I don't quite understand your point. Are you saying that if all the
TRBs are very short, you might need more than 64 TRBs to reach a 16-KB
boundary?
> For bulk data the link TRB can be forced at a packet boundary
> by splitting the TD up - the receiving end won't know the difference.
That won't work. What happens if you split a TD up into two pieces and
the first piece receives a short packet? The host controller will
automatically move to the start of the second piece. That's not what
we want.
> > It comes down to a question of how often you want the controller to
> > issue an interrupt. If a ring segment is 4 KB (one page), then it can
> > hold 256 TRBs. With scatter-gather transfers, each SG element
> > typically refers to something like a 2-page buffer (depends on how
> > fragmented the memory is). Therefore a ring segment will describe
> > somewhere around 512 pages of data, i.e., something like 2 MB. Since
> > SuperSpeed is 500 MB/s, you'd end up getting in the vicinity of 250
> > interrupts every second just because of ring segment crossings.
>
> 250 interrupts/sec is noise. Send/receive 13000 ethernet packets/sec
> and then look at the interrupt rate!
>
> There is no necessity for taking an interrupt from every link segment.
Yes, there is. The HCD needs to know when the dequeue pointer has
moved beyond the end of the ring segment, so that it can start reusing
the TRB slots in that segment.
Suppose you have queued a bulk URB because there weren't enough free
TRB slots. How else would you know when the occupied slots became
available?
> The current ring segments contain 64 entries, a strange choice
> since they are created with 2 segments.
> (The ring expansion code soon doubles that for my ethernet traffic.)
>
> I would change the code to use a single segment (for coding simplicity)
> and queue bulk URB when there isn't enough ring space.
> URB with too many fragments could either be rejected, sent in sections,
> or partially linearised (and probably still sent in sections).
Rejecting an URB is not feasible. Splitting it up into multiple TDs is
not acceptable, as explained above. Sending it in sections (i.e.,
queueing only some of the TRBs at any time) would work, provided you
got at least two interrupts every time the queue wrapped around (which
suggests you might want at least two ring segments).
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipvs: Remove unused variable ret from sync_thread_master()
From: Oleg Nesterov @ 2013-11-12 16:21 UTC (permalink / raw)
To: Peter Zijlstra, Tejun Heo
Cc: David Laight, Geert Uytterhoeven, Ingo Molnar, netdev,
linux-kernel
In-Reply-To: <20131112145243.GU5056@laptop.programming.kicks-ass.net>
On 11/12, Peter Zijlstra wrote:
>
> On Tue, Nov 12, 2013 at 02:21:39PM -0000, David Laight wrote:
> > Shame there isn't a process flag to indicate that the process
> > will sleep uninterruptibly and that it doesn't matter.
> > So don't count to the load average and don't emit a warning
> > if it has been sleeping for a long time.
>
> A process flag wouldn't work, because the task could block waiting for
> actual work to complete in other sleeps.
>
> However, we could do something like the below; which would allow us
> writing things like:
>
> (void)___wait_event(*sk_sleep(sk),
> sock_writeable(sk) || kthread_should_stop(),
> TASK_UNINTERRUPTIBLE | TASK_IDLE, 0, 0,
> schedule());
>
> Marking the one wait-for-more-work as TASK_IDLE such that it doesn't
> contribute to the load avg.
Agreed, I thought about additional bit too.
> static const char * const task_state_array[] = {
> - "R (running)", /* 0 */
> - "S (sleeping)", /* 1 */
> - "D (disk sleep)", /* 2 */
> - "T (stopped)", /* 4 */
> - "t (tracing stop)", /* 8 */
> - "Z (zombie)", /* 16 */
> - "X (dead)", /* 32 */
> - "x (dead)", /* 64 */
> - "K (wakekill)", /* 128 */
> - "W (waking)", /* 256 */
> - "P (parked)", /* 512 */
> + "R (running)", /* 0 */
> + "S (sleeping)", /* 1 */
> + "D (disk sleep)", /* 2 */
> + "T (stopped)", /* 4 */
> + "t (tracing stop)", /* 8 */
> + "Z (zombie)", /* 16 */
> + "X (dead)", /* 32 */
> + "x (dead)", /* 64 */
> + "K (wakekill)", /* 128 */
> + "W (waking)", /* 256 */
> + "P (parked)", /* 512 */
> + "I (idle)", /* 1024 */
> };
but I am not sure about what /proc/ should report in this case...
> #define task_contributes_to_load(task) \
> ((task->state & TASK_UNINTERRUPTIBLE) != 0 && \
> - (task->flags & PF_FROZEN) == 0)
> + (task->flags & PF_FROZEN) == 0 && \
> + (task->state & TASK_IDLE) == 0)
perhaps
(task->state & (TASK_UNINTERRUPTIBLE | TASK_IDLE)) == TASK_UNINTERRUPTIBLE
can save an insn.
I am also wondering if it makes any sense to turn PF_FROZEN into
TASK_FROZEN, something like (incomplete, probably racy) patch below.
Note that it actually adds the new state, not the the qualifier.
Oleg.
--- x/include/linux/freezer.h
+++ x/include/linux/freezer.h
@@ -23,7 +23,7 @@ extern unsigned int freeze_timeout_msecs
*/
static inline bool frozen(struct task_struct *p)
{
- return p->flags & PF_FROZEN;
+ return p->state & TASK_FROZEN;
}
extern bool freezing_slow_path(struct task_struct *p);
--- x/kernel/freezer.c
+++ x/kernel/freezer.c
@@ -57,16 +57,13 @@ bool __refrigerator(bool check_kthr_stop
pr_debug("%s entered refrigerator\n", current->comm);
for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
-
spin_lock_irq(&freezer_lock);
- current->flags |= PF_FROZEN;
- if (!freezing(current) ||
- (check_kthr_stop && kthread_should_stop()))
- current->flags &= ~PF_FROZEN;
+ if (freezing(current) &&
+ !(check_kthr_stop && kthread_should_stop()))
+ set_current_state(TASK_FROZEN);
spin_unlock_irq(&freezer_lock);
- if (!(current->flags & PF_FROZEN))
+ if (!(current->state & TASK_FROZEN))
break;
was_frozen = true;
schedule();
@@ -148,8 +145,7 @@ void __thaw_task(struct task_struct *p)
* refrigerator.
*/
spin_lock_irqsave(&freezer_lock, flags);
- if (frozen(p))
- wake_up_process(p);
+ try_to_wake_up(p, TASK_FROZEN, 0);
spin_unlock_irqrestore(&freezer_lock, flags);
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox