* Re: [PATCH v8 1/9] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-12-09 12:40 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, lizf-BthXqXjhjHXQFUHtdCDX3A,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gthelen-hpIqsD4AKlfQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, kirill-oKw7cIdHH8eLwutG50LtGA,
avagin-bzQdu9zFT3WakBO8gow8eQ, devel-GEFAQzZX7r8dnm+yROfE0A,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, hannes-druUgvl0LCNAfugRpC6u6w,
mhocko-AlSwsSmVLrQ, Paul Menage
In-Reply-To: <20111209102113.cdb85da8.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 12/08/2011 11:21 PM, KAMEZAWA Hiroyuki wrote:
> On Mon, 5 Dec 2011 19:34:55 -0200
> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
>
>> This patch lays down the foundation for the kernel memory component
>> of the Memory Controller.
>>
>> As of today, I am only laying down the following files:
>>
>> * memory.independent_kmem_limit
>> * memory.kmem.limit_in_bytes (currently ignored)
>> * memory.kmem.usage_in_bytes (always zero)
>>
>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>> Reviewed-by: Kirill A. Shutemov<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
>> CC: Paul Menage<paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org>
>> CC: Greg Thelen<gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>
> As I wrote, please CC Johannes and Michal Hocko for memcg related parts.
I forgot to add them to the patch itself, but they are in the CC list of
the messages.
So they did get the mail.
> A few questions.
> ==
>> + val = !!val;
>> +
>> + if (parent&& parent->use_hierarchy&&
>> + (val != parent->kmem_independent_accounting))
>> + return -EINVAL;
> ==
> Hm, why you check val != parent->kmem_independent_accounting ?
>
> if (parent&& parent->use_hierarchy)
> return -EINVAL;
> ?
Because I thought that making sure that everybody in the chain is
consistent, it will make things simpler for us. But I am happy to change
that if you prefer.
> BTW, you didn't check this cgroup has children or not.
> I think
>
> if (this_cgroup->use_hierarchy&&
> !list_empty(this_cgroup->childlen))
> return -EINVAL;
>
Noted.
> ==
>> + /*
>> + * TODO: We need to handle the case in which we are doing
>> + * independent kmem accounting as authorized by our parent,
>> + * but then our parent changes its parameter.
>> + */
>> + cgroup_lock();
>> + memcg->kmem_independent_accounting = val;
>> + cgroup_unlock();
>
> Do we need cgroup_lock() here ?
Well, I removed almost all instances of it from previous patches, so I
guess this one can go as well.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" 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 v8 2/9] foundations of per-cgroup memory pressure controlling.
From: Glauber Costa @ 2011-12-09 12:41 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, lizf, ebiederm, davem, gthelen, netdev, linux-mm,
kirill, avagin, devel, eric.dumazet, cgroups, hannes, mhocko
In-Reply-To: <20111209102438.2db705d0.kamezawa.hiroyu@jp.fujitsu.com>
On 12/08/2011 11:24 PM, KAMEZAWA Hiroyuki wrote:
> On Mon, 5 Dec 2011 19:34:56 -0200
> Glauber Costa<glommer@parallels.com> wrote:
>
>> This patch replaces all uses of struct sock fields' memory_pressure,
>> memory_allocated, sockets_allocated, and sysctl_mem to acessor
>> macros. Those macros can either receive a socket argument, or a mem_cgroup
>> argument, depending on the context they live in.
>>
>> Since we're only doing a macro wrapping here, no performance impact at all is
>> expected in the case where we don't have cgroups disabled.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>> CC: Eric Dumazet<eric.dumazet@gmail.com>
>
> please get ack from network guys.
> from me.
> Reviewed-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
>
Ok.
I think that now with all the Reviewed-by:'s I will resend it as a
Request for Inclusion for Dave (plus fixing the problem you noted in
patch 1)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 3/9] socket: initial cgroup code.
From: Glauber Costa @ 2011-12-09 12:43 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, lizf, ebiederm, davem, gthelen, netdev, linux-mm,
kirill, avagin, devel, eric.dumazet, cgroups, hannes, mhocko,
KAMEZAWA Hiroyuki
In-Reply-To: <20111209110550.fc740b81.kamezawa.hiroyu@jp.fujitsu.com>
On 12/09/2011 12:05 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 5 Dec 2011 19:34:57 -0200
> Glauber Costa<glommer@parallels.com> wrote:
>
>> The goal of this work is to move the memory pressure tcp
>> controls to a cgroup, instead of just relying on global
>> conditions.
>>
>> To avoid excessive overhead in the network fast paths,
>> the code that accounts allocated memory to a cgroup is
>> hidden inside a static_branch(). This branch is patched out
>> until the first non-root cgroup is created. So when nobody
>> is using cgroups, even if it is mounted, no significant performance
>> penalty should be seen.
>>
>> This patch handles the generic part of the code, and has nothing
>> tcp-specific.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: Kirill A. Shutemov<kirill@shutemov.name>
>> CC: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujtsu.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>> CC: Eric Dumazet<eric.dumazet@gmail.com>
>
> I already replied Reviewed-by: but...
Feel free. Reviews, the more, the merrier.
>
>
>> +/* Writing them here to avoid exposing memcg's inner layout */
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +#ifdef CONFIG_INET
>> +#include<net/sock.h>
>> +
>> +static bool mem_cgroup_is_root(struct mem_cgroup *memcg);
>> +void sock_update_memcg(struct sock *sk)
>> +{
>> + /* A socket spends its whole life in the same cgroup */
>> + if (sk->sk_cgrp) {
>> + WARN_ON(1);
>> + return;
>> + }
>> + if (static_branch(&memcg_socket_limit_enabled)) {
>> + struct mem_cgroup *memcg;
>> +
>> + BUG_ON(!sk->sk_prot->proto_cgroup);
>> +
>> + rcu_read_lock();
>> + memcg = mem_cgroup_from_task(current);
>> + if (!mem_cgroup_is_root(memcg)) {
>> + mem_cgroup_get(memcg);
>> + sk->sk_cgrp = sk->sk_prot->proto_cgroup(memcg);
>> + }
>> + rcu_read_unlock();
>> + }
>> +}
>
> Here, you do mem_cgroup_get() if !mem_cgroup_is_root().
>
>
>> +EXPORT_SYMBOL(sock_update_memcg);
>> +
>> +void sock_release_memcg(struct sock *sk)
>> +{
>> + if (static_branch(&memcg_socket_limit_enabled)&& sk->sk_cgrp) {
>> + struct mem_cgroup *memcg;
>> + WARN_ON(!sk->sk_cgrp->memcg);
>> + memcg = sk->sk_cgrp->memcg;
>> + mem_cgroup_put(memcg);
>> + }
>> +}
>>
>
> You don't check !mem_cgroup_is_root(). Hm, root memcg will not be freed
> by this ?
>
No, I don't. But I check if sk->sk_cgrp is filled. So it is implied,
because we only fill in this value if !mem_cgroup_is_root().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH net-next] sch_red: generalize accurate MAX_P support to RED/GRED/CHOKE
From: Eric Dumazet @ 2011-12-09 12:46 UTC (permalink / raw)
To: Stephen Hemminger, David Miller; +Cc: Dave Taht, netdev, Hagen Paul Pfeifer
In-Reply-To: <1323368188.2529.4.camel@edumazet-laptop>
Now RED uses a Q0.32 number to store max_p (max probability), allow
RED/GRED/CHOKE to use/report full resolution at config/dump time.
Old tc binaries are non aware of new attributes, and still set/get Plog.
New tc binary set/get both Plog and max_p for backward compatibility,
they display "probability value" if they get max_p from new kernels.
# tc -d qdisc show dev ...
...
qdisc red 10: parent 1:1 limit 360Kb min 30Kb max 90Kb ecn ewma 5
probability 0.09 Scell_log 15
Make sure we avoid potential divides by 0 in reciprocal_value(), if
(max_th - min_th) is big.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/pkt_sched.h | 2 ++
include/net/red.h | 16 +++++++++++-----
net/sched/sch_choke.c | 8 +++++++-
net/sched/sch_gred.c | 22 ++++++++++++++++++----
net/sched/sch_red.c | 9 +++++++--
5 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index e41e0d4..8786ea7 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -216,6 +216,7 @@ enum {
TCA_GRED_PARMS,
TCA_GRED_STAB,
TCA_GRED_DPS,
+ TCA_GRED_MAX_P,
__TCA_GRED_MAX,
};
@@ -255,6 +256,7 @@ enum {
TCA_CHOKE_UNSPEC,
TCA_CHOKE_PARMS,
TCA_CHOKE_STAB,
+ TCA_CHOKE_MAX_P,
__TCA_CHOKE_MAX,
};
diff --git a/include/net/red.h b/include/net/red.h
index 24606b2..ef715a1 100644
--- a/include/net/red.h
+++ b/include/net/red.h
@@ -155,9 +155,10 @@ static inline u32 red_maxp(u8 Plog)
static inline void red_set_parms(struct red_parms *p,
u32 qth_min, u32 qth_max, u8 Wlog, u8 Plog,
- u8 Scell_log, u8 *stab)
+ u8 Scell_log, u8 *stab, u32 max_P)
{
int delta = qth_max - qth_min;
+ u32 max_p_delta;
/* Reset average queue length, the value is strictly bound
* to the parameters below, reseting hurts a bit but leaving
@@ -173,10 +174,14 @@ static inline void red_set_parms(struct red_parms *p,
if (delta < 0)
delta = 1;
p->qth_delta = delta;
- p->max_P = red_maxp(Plog);
- p->max_P *= delta; /* max_P = (qth_max-qth_min)/2^Plog */
-
- p->max_P_reciprocal = reciprocal_value(p->max_P / delta);
+ if (!max_P) {
+ max_P = red_maxp(Plog);
+ max_P *= delta; /* max_P = (qth_max - qth_min)/2^Plog */
+ }
+ p->max_P = max_P;
+ max_p_delta = max_P / delta;
+ max_p_delta = max(max_p_delta, 1U);
+ p->max_P_reciprocal = reciprocal_value(max_p_delta);
/* RED Adaptative target :
* [min_th + 0.4*(min_th - max_th),
@@ -380,6 +385,7 @@ static inline void red_adaptative_algo(struct red_parms *p)
p->max_P = (p->max_P/10)*9; /* maxp = maxp * Beta */
max_p_delta = DIV_ROUND_CLOSEST(p->max_P, p->qth_delta);
+ max_p_delta = max(max_p_delta, 1U);
p->max_P_reciprocal = reciprocal_value(max_p_delta);
}
#endif
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index 205d369..bef00ac 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -394,6 +394,7 @@ static void choke_reset(struct Qdisc *sch)
static const struct nla_policy choke_policy[TCA_CHOKE_MAX + 1] = {
[TCA_CHOKE_PARMS] = { .len = sizeof(struct tc_red_qopt) },
[TCA_CHOKE_STAB] = { .len = RED_STAB_SIZE },
+ [TCA_CHOKE_MAX_P] = { .type = NLA_U32 },
};
@@ -415,6 +416,7 @@ static int choke_change(struct Qdisc *sch, struct nlattr *opt)
int err;
struct sk_buff **old = NULL;
unsigned int mask;
+ u32 max_P;
if (opt == NULL)
return -EINVAL;
@@ -427,6 +429,8 @@ static int choke_change(struct Qdisc *sch, struct nlattr *opt)
tb[TCA_CHOKE_STAB] == NULL)
return -EINVAL;
+ max_P = tb[TCA_CHOKE_MAX_P] ? nla_get_u32(tb[TCA_CHOKE_MAX_P]) : 0;
+
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
if (ctl->limit > CHOKE_MAX_QUEUE)
@@ -476,7 +480,8 @@ static int choke_change(struct Qdisc *sch, struct nlattr *opt)
red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
ctl->Plog, ctl->Scell_log,
- nla_data(tb[TCA_CHOKE_STAB]));
+ nla_data(tb[TCA_CHOKE_STAB]),
+ max_P);
if (q->head == q->tail)
red_end_of_idle_period(&q->parms);
@@ -510,6 +515,7 @@ static int choke_dump(struct Qdisc *sch, struct sk_buff *skb)
goto nla_put_failure;
NLA_PUT(skb, TCA_CHOKE_PARMS, sizeof(opt), &opt);
+ NLA_PUT_U32(skb, TCA_CHOKE_MAX_P, q->parms.max_P);
return nla_nest_end(skb, opts);
nla_put_failure:
diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index b9493a0..2e830c8 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -34,7 +34,7 @@ struct gred_sched;
struct gred_sched_data {
u32 limit; /* HARD maximal queue length */
- u32 DP; /* the drop pramaters */
+ u32 DP; /* the drop parameters */
u32 bytesin; /* bytes seen on virtualQ so far*/
u32 packetsin; /* packets seen on virtualQ so far*/
u32 backlog; /* bytes on the virtualQ */
@@ -379,7 +379,8 @@ static inline int gred_change_table_def(struct Qdisc *sch, struct nlattr *dps)
}
static inline int gred_change_vq(struct Qdisc *sch, int dp,
- struct tc_gred_qopt *ctl, int prio, u8 *stab)
+ struct tc_gred_qopt *ctl, int prio,
+ u8 *stab, u32 max_P)
{
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q;
@@ -400,7 +401,7 @@ static inline int gred_change_vq(struct Qdisc *sch, int dp,
red_set_parms(&q->parms,
ctl->qth_min, ctl->qth_max, ctl->Wlog, ctl->Plog,
- ctl->Scell_log, stab);
+ ctl->Scell_log, stab, max_P);
return 0;
}
@@ -409,6 +410,7 @@ static const struct nla_policy gred_policy[TCA_GRED_MAX + 1] = {
[TCA_GRED_PARMS] = { .len = sizeof(struct tc_gred_qopt) },
[TCA_GRED_STAB] = { .len = 256 },
[TCA_GRED_DPS] = { .len = sizeof(struct tc_gred_sopt) },
+ [TCA_GRED_MAX_P] = { .type = NLA_U32 },
};
static int gred_change(struct Qdisc *sch, struct nlattr *opt)
@@ -418,6 +420,7 @@ static int gred_change(struct Qdisc *sch, struct nlattr *opt)
struct nlattr *tb[TCA_GRED_MAX + 1];
int err, prio = GRED_DEF_PRIO;
u8 *stab;
+ u32 max_P;
if (opt == NULL)
return -EINVAL;
@@ -433,6 +436,8 @@ static int gred_change(struct Qdisc *sch, struct nlattr *opt)
tb[TCA_GRED_STAB] == NULL)
return -EINVAL;
+ max_P = tb[TCA_GRED_MAX_P] ? nla_get_u32(tb[TCA_GRED_MAX_P]) : 0;
+
err = -EINVAL;
ctl = nla_data(tb[TCA_GRED_PARMS]);
stab = nla_data(tb[TCA_GRED_STAB]);
@@ -457,7 +462,7 @@ static int gred_change(struct Qdisc *sch, struct nlattr *opt)
sch_tree_lock(sch);
- err = gred_change_vq(sch, ctl->DP, ctl, prio, stab);
+ err = gred_change_vq(sch, ctl->DP, ctl, prio, stab, max_P);
if (err < 0)
goto errout_locked;
@@ -498,6 +503,7 @@ static int gred_dump(struct Qdisc *sch, struct sk_buff *skb)
struct gred_sched *table = qdisc_priv(sch);
struct nlattr *parms, *opts = NULL;
int i;
+ u32 max_p[MAX_DPs];
struct tc_gred_sopt sopt = {
.DPs = table->DPs,
.def_DP = table->def,
@@ -509,6 +515,14 @@ static int gred_dump(struct Qdisc *sch, struct sk_buff *skb)
if (opts == NULL)
goto nla_put_failure;
NLA_PUT(skb, TCA_GRED_DPS, sizeof(sopt), &sopt);
+
+ for (i = 0; i < MAX_DPs; i++) {
+ struct gred_sched_data *q = table->tab[i];
+
+ max_p[i] = q ? q->parms.max_P : 0;
+ }
+ NLA_PUT(skb, TCA_GRED_MAX_P, sizeof(max_p), max_p);
+
parms = nla_nest_start(skb, TCA_GRED_PARMS);
if (parms == NULL)
goto nla_put_failure;
diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
index 8f5a85b..ce2256a 100644
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -170,6 +170,7 @@ static void red_destroy(struct Qdisc *sch)
static const struct nla_policy red_policy[TCA_RED_MAX + 1] = {
[TCA_RED_PARMS] = { .len = sizeof(struct tc_red_qopt) },
[TCA_RED_STAB] = { .len = RED_STAB_SIZE },
+ [TCA_RED_MAX_P] = { .type = NLA_U32 },
};
static int red_change(struct Qdisc *sch, struct nlattr *opt)
@@ -179,6 +180,7 @@ static int red_change(struct Qdisc *sch, struct nlattr *opt)
struct tc_red_qopt *ctl;
struct Qdisc *child = NULL;
int err;
+ u32 max_P;
if (opt == NULL)
return -EINVAL;
@@ -191,6 +193,8 @@ static int red_change(struct Qdisc *sch, struct nlattr *opt)
tb[TCA_RED_STAB] == NULL)
return -EINVAL;
+ max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
+
ctl = nla_data(tb[TCA_RED_PARMS]);
if (ctl->limit > 0) {
@@ -209,8 +213,9 @@ static int red_change(struct Qdisc *sch, struct nlattr *opt)
}
red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
- ctl->Plog, ctl->Scell_log,
- nla_data(tb[TCA_RED_STAB]));
+ ctl->Plog, ctl->Scell_log,
+ nla_data(tb[TCA_RED_STAB]),
+ max_P);
del_timer(&q->adapt_timer);
if (ctl->flags & TC_RED_ADAPTATIVE)
^ permalink raw reply related
* VERY URGENT===========READ ATTACHMENT
From: FBI OFFICE @ 2011-12-09 21:21 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 16 bytes --]
OPEN ATTACHMENT
[-- Attachment #2: FBI NOTICE 1.txt --]
[-- Type: application/octet-stream, Size: 2376 bytes --]
ANTI-TERRORIST AND MONETARY CRIMES DIVISION
FBI HEADQUARTERS IN WASHINGTON, D.C.
Federal Bureau Of Investigation.
FBI-Washington Field Office
601 4th Street, NW
Washington, DC 20535
DATE:12/09/2011
It has been discovered that your contract/inheritance/winning FUND was about being transferred to an unknown account under your name. This attempt was perpetrated by someone who claims to be working for you, and that you have given him due authority to have the FUND moved to the account specified below:
SOUTHWESTERN FEDERAL CREDIT UNION
WESCORP 924 OVERLAND COURT
SAN DIMAS, CA 91772. USA.
ACCOUNT NUMBER: 322682133
ABA/ROUTING NUMBER: 1211-71-41-8
SHARETYPE NO.: 35
FINAL CREDIT JOHNSON FENZI AND CO. (Beneficiary).
The Federal Bureau of Investigation (F.B.I.) waded in after being alerted by the supposed bank. We investigated and found that there is a possible money laundering activity in play.The FUND US$10,500,000.00(Ten Million Five Hundred Thousand United States Dollars) was found to be deposited in Bank of America in your name pending your consent to have it transferred to the new account indicated above. It was further revealed that initial FUND transfer originated from Nigeria to England and now here in Bank of America in USA.
These transfers did not follow due process in line with the international FUND transfer rules and regulation.Consequently,we suspect this to be a terrorism funding, drug related fund deposit and/or money laundering. As stated above, the FUND has your name on it;and you must have it cleared of any connection with any of these illegal activities for immediate release and transfer of fund to you in accordance to the law.
Finally, you are expected to have the US PERMIT AUTHORIZATION of TRANSFER (UPAT) CLEARANCE DOCUMENT obtain from where the FUND originated from to have you and your fund cleared.Only then shall we release your FUND as clean money devoid of any illegality.Get back to me immediately for contact information of the Anti Graft Department California branch office as they will procure your UPAT CLEARANCE DOCUMENT and send to my office for your clearance to receive your fund.
I will be waiting to hear from you.
Faithfully Yours
Robert S. Mueller III
FBI Director
Federal Bureau Of Investigation.
FBI-Washington Field Office
601 4th Street, NW
Washington, DC 20535
^ permalink raw reply
* Re: TCP fast retransmit
From: Esztermann, Ansgar @ 2011-12-09 13:34 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <1322239016.5793.12.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
On Nov 25, 2011, at 17:36 , Eric Dumazet wrote:
> Could you send a sample pcap of such problem, but please include full
> tcp sesssion, from the first SYN packet, up to packets following
> restransmits.
OK, I've got a dump now. It is rather large (>300MB), so it's probably not a good idea to send it to the list. Instead, you can find it here:
http://wwwuser.gwdg.de/~aeszter/tcpstream.pcap
The capture has been taken in the sender, 10.208.9.87, with a capture filter on the receiver's IP address. OS is:
% uname -a
Linux mwolf 2.6.37.6-0.9-default #1 SMP 2011-10-19 22:33:27 +0200 x86_64 x86_64 x86_64 GNU/Linux
The first "strange" retransmission is in frame 166859, following ACKs in frames 166849 .. 166858.
If I can do anything to reduce the amount of data, I will of course do so.
> A diff of "netstat -s" taken before your session and after your session
> on receiver would help too, if receiver is not a loaded machine of
> course.
Attached.
Thanks a lot,
A.
--
Ansgar Esztermann
DV-Systemadministration
Max-Planck-Institut für biophysikalische Chemie, Abteilung 105
[-- Attachment #2: netstat.diff --]
[-- Type: application/octet-stream, Size: 4185 bytes --]
--- /tmp/before 2011-12-09 12:16:46.000000000 +0100
+++ /tmp/after 2011-12-09 12:24:33.000000000 +0100
@@ -1,10 +1,10 @@
Ip:
- 1072587745 total packets received
+ 1072859058 total packets received
151 with invalid addresses
0 forwarded
0 incoming packets discarded
- 1072579855 incoming packets delivered
- 638884639 requests sent out
+ 1072850362 incoming packets delivered
+ 639060780 requests sent out
Icmp:
78 ICMP messages received
1 input ICMP message failed.
@@ -24,21 +24,21 @@
OutType3: 117
OutType8: 287
Tcp:
- 48789 active connections openings
- 26811 passive connection openings
+ 48801 active connections openings
+ 26814 passive connection openings
132 failed connection attempts
1153 connection resets received
- 20 connections established
- 1061726671 segments received
- 3164994399 segments send out
- 40400659 segments retransmited
+ 23 connections established
+ 1061994682 segments received
+ 3165601316 segments send out
+ 40407999 segments retransmited
0 bad segments received.
2272 resets sent
Udp:
- 9868225 packets received
+ 9870499 packets received
44 packets to unknown port received.
0 packet receive errors
- 444603 packets sent
+ 444689 packets sent
RcvbufErrors: 0
SndbufErrors: 0
UdpLite:
@@ -53,18 +53,18 @@
13 packets pruned from receive queue because of socket buffer overrun
33 ICMP packets dropped because they were out-of-window
ArpFilter: 0
- 29164 TCP sockets finished time wait in fast timer
+ 29177 TCP sockets finished time wait in fast timer
43 packets rejects in established connections because of timestamp
- 287177 delayed acks sent
- 527 delayed acks further delayed because of locked socket
- Quick ack mode was activated 15340 times
+ 287884 delayed acks sent
+ 528 delayed acks further delayed because of locked socket
+ Quick ack mode was activated 15590 times
49278 packets directly queued to recvmsg prequeue.
- 1803084 packets directly received from backlog
+ 1804188 packets directly received from backlog
176281729 packets directly received from prequeue
- 121263452 packets header predicted
- 50350 packets header predicted and directly queued to user
- TCPPureAcks: 287487005
- TCPHPAcks: 627694332
+ 121375107 packets header predicted
+ 50351 packets header predicted and directly queued to user
+ TCPPureAcks: 287534908
+ TCPHPAcks: 627801067
TCPRenoRecovery: 0
TCPSackRecovery: 286
TCPSACKReneging: 0
@@ -79,17 +79,17 @@
TCPLoss: 104
TCPLostRetransmit: 0
TCPRenoFailures: 0
- TCPSackFailures: 112431
- TCPLossFailures: 77046
+ TCPSackFailures: 112458
+ TCPLossFailures: 77061
TCPFastRetrans: 3654
TCPForwardRetrans: 1
- TCPSlowStartRetrans: 34571085
- TCPTimeouts: 5586734
+ TCPSlowStartRetrans: 34577497
+ TCPTimeouts: 5587603
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 64
TCPSchedulerFailed: 0
TCPRcvCollapsed: 1875
- TCPDSACKOldSent: 12229
+ TCPDSACKOldSent: 12479
TCPDSACKOfoSent: 428
TCPDSACKRecv: 92820540
TCPDSACKOfoRecv: 0
@@ -101,7 +101,7 @@
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0
- TCPSACKDiscard: 20059268
+ TCPSACKDiscard: 20074900
TCPDSACKIgnoredOld: 24637182
TCPDSACKIgnoredNoUndo: 68178807
TCPSpuriousRTOs: 25
@@ -118,13 +118,13 @@
IpExt:
InNoRoutes: 0
InTruncatedPkts: 0
- InMcastPkts: 9564962
- OutMcastPkts: 130464
- InBcastPkts: 983842
+ InMcastPkts: 9567193
+ OutMcastPkts: 130499
+ InBcastPkts: 984064
OutBcastPkts: 0
- InOctets: 718897124903
- OutOctets: 4260817429624
- InMcastOctets: 1697591676
- OutMcastOctets: 19340504
- InBcastOctets: 138610857
+ InOctets: 719247299280
+ OutOctets: 4261557593433
+ InMcastOctets: 1697945778
+ OutMcastOctets: 19344841
+ InBcastOctets: 138637486
OutBcastOctets: 0
^ permalink raw reply
* Re: [PATCH 0/4] skb paged fragment destructors
From: Ian Campbell @ 2011-12-09 13:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Jesse Brandeburg, netdev@vger.kernel.org
In-Reply-To: <1323264929.23681.178.camel@zakaz.uk.xensource.com>
On Wed, 2011-12-07 at 13:35 +0000, Ian Campbell wrote:
> On Tue, 2011-12-06 at 13:24 +0000, Eric Dumazet wrote:
> > Le mardi 06 décembre 2011 à 11:57 +0000, Ian Campbell a écrit :
> > > On Wed, 2011-11-09 at 15:01 +0000, Ian Campbell wrote:
> > > > * split linear data allocation and shinfo allocation into two. I
> > > > suspect this will have its own performance implications? On the
> > > > positive side skb_shared_info could come from its own fixed size
> > > > pool/cache which might have some benefits
> > >
> > > I played with this to see how it would look. Illustrative patch below.
> > >
> > > I figure that lots of small frames is the interesting workload for a
> > > change such as this but I don't know if iperf is necessarily the best
> > > benchmark for measuring that.
> > > Before changing things I got:
> > > iperf -c qarun -m -t 60 -u -b 10000M -l 64
> > > ------------------------------------------------------------
> > > Client connecting to qarun, UDP port 5001
> > > Sending 64 byte datagrams
> > > UDP buffer size: 224 KByte (default)
> > > ------------------------------------------------------------
> > > [ 3] local 10.80.225.63 port 45857 connected with 10.80.224.22 port 5001
> > > [ ID] Interval Transfer Bandwidth
> > > [ 3] 0.0-60.0 sec 844 MBytes 118 Mbits/sec
> > > [ 3] Sent 13820376 datagrams
> > > [ 3] Server Report:
> > > [ 3] 0.0-60.0 sec 844 MBytes 118 Mbits/sec 0.005 ms 0/13820375 (0%)
> > > [ 3] 0.0-60.0 sec 1 datagrams received out-of-order
> > > whereas with the patch:
> > > # iperf -c qarun -m -t 60 -u -b 10000M -l 64
> > > ------------------------------------------------------------
> > > Client connecting to qarun, UDP port 5001
> > > Sending 64 byte datagrams
> > > UDP buffer size: 224 KByte (default)
> > > ------------------------------------------------------------
> > > [ 3] local 10.80.225.63 port 42504 connected with 10.80.224.22 port 5001
> > > [ ID] Interval Transfer Bandwidth
> > > [ 3] 0.0-60.0 sec 833 MBytes 116 Mbits/sec
> > > [ 3] Sent 13645857 datagrams
> > > [ 3] Server Report:
> > > [ 3] 0.0-60.0 sec 833 MBytes 116 Mbits/sec 0.005 ms 0/13645856 (0%)
> > > [ 3] 0.0-60.0 sec 1 datagrams received out-of-order
> > >
> > > With 1200 byte datagrams I get basically identical throughput.
> > >
> > > (nb: none of the skb destructor stuff was present in either case)
> >
> > Sorry, but the real problem is that if skb producer and consumer are not
> > on same CPU, each skb will now hit SLUB slowpath three times instead of
> > two.
> >
> > Some workloads are : One cpu fully handling IRQ from device, dispatching
> > skbs to consumers on other cpus.
>
> So something like a multithreaded apache benchmark would be interesting?
>
> > Plus skb->truesize is wrong after your patch.
> > Not sure if cloning is correct either...
>
> Me neither, the patch was just one which happened to run well enough to
> run some numbers on. I'll be sure to double-check/correct that stuff if
> I persist with the approach.
>
> > Anyway, do we _really_ need 16 frags per skb, I dont know....
>
> MAX_SKB_FRAGS is:
> /* To allow 64K frame to be packed as single skb without frag_list. Since
> * GRO uses frags we allocate at least 16 regardless of page size.
> */
> #if (65536/PAGE_SIZE + 2) < 16
> #define MAX_SKB_FRAGS 16UL
> #else
> #define MAX_SKB_FRAGS (65536/PAGE_SIZE + 2)
> #endif
>
> So I think actually it turns out to be 18 on systems with 4k pages. If
> we reduced that to be 16 that would save 48 bytes on amd64 which pulls
> the shinfo size down to 440 and then
>
> NET_SKB_PAD (64) + 1500 + 14 + 440 = 2018
>
> which does fit in half a page.
>
> Using 16 still means that a 64k frame fits precisely in frags on a 4096
> page size system. I don't know what the extra 2 was for (it predates
> git), perhaps just to allow for some slop due to misalignment in the
> first page of data?
Tracked it down in TGLX's historic tree as:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=80223d5186f73bf42a7e260c66c9cb9f7d8ec9cf
Having found the title I did a bit of searching around for discussion
but all I could find was other folks not having any idea where the + 2
comes from either...
http://kerneltrap.org/mailarchive/linux-netdev/2008/4/21/1529914 sort of
wonders if the + 2 might be including a head which crosses a page
boundary. I'm not sure it is sane/useful to account for that in
MAX_SKB_FRAGS. If we had a concept like MAX_SKB_PAGES then it would
perhaps make sense to have + 2 there, but AFAICT drivers etc are already
accounting for this appropriately by adding a further + 2 (or sometimes
+ 1) to MAX_SKB_FRAGS.
Ian.
>
> > This gives problems when/if skb must be linearized and we hit
> > PAGE_ALLOC_COSTLY_ORDER
> >
> > Alternatively, we could use order-1 or order-2 pages on x86 to get
> > 8192/16384 bytes frags. (fallback to order-0 pages in case of allocation
> > failures)
>
> Or fallback to separate allocation of shinfo?
>
> Ian.
>
>
>
> --
> 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
* [PATCH] flexcan: Acknowledge all interrupt sources in the IRQ handler
From: Lothar Waßmann @ 2011-12-09 13:47 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linux-can, netdev, linux-kernel, Lothar Waßmann
Otherwise the handler will get stuck in an endless IRQ loop when an
interrupt condition occurs that is not being acked (e.g. TWRN)
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/net/can/flexcan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index e023379..ea8f04d 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -577,7 +577,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
reg_iflag1 = flexcan_read(®s->iflag1);
reg_esr = flexcan_read(®s->esr);
- flexcan_write(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
+ flexcan_write(reg_esr, ®s->esr); /* ACK all IRQs */
/*
* schedule NAPI in case of:
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] flexcan: Acknowledge all interrupt sources in the IRQ handler
From: Marc Kleine-Budde @ 2011-12-09 13:52 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <1323438454-6816-1-git-send-email-LW@KARO-electronics.de>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
On 12/09/2011 02:47 PM, Lothar Waßmann wrote:
> Otherwise the handler will get stuck in an endless IRQ loop when an
> interrupt condition occurs that is not being acked (e.g. TWRN)
On which CPU do you have this problem?
Seems that mx25/35 behave a bit different than mx28. But I had no time
to dig into this, yet. BTW Wolfgang is just reworking error handling,
can you please test his patches he recently posted on linux-can.
cheers, Marc
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> ---
> drivers/net/can/flexcan.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> index e023379..ea8f04d 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -577,7 +577,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
>
> reg_iflag1 = flexcan_read(®s->iflag1);
> reg_esr = flexcan_read(®s->esr);
> - flexcan_write(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
> + flexcan_write(reg_esr, ®s->esr); /* ACK all IRQs */
>
> /*
> * schedule NAPI in case of:
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH] flexcan: Acknowledge all interrupt sources in the IRQ handler
From: Lothar Waßmann @ 2011-12-09 13:59 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <4EE212AE.40005@pengutronix.de>
Hi,
Marc Kleine-Budde writes:
> On 12/09/2011 02:47 PM, Lothar Waßmann wrote:
> > Otherwise the handler will get stuck in an endless IRQ loop when an
> > interrupt condition occurs that is not being acked (e.g. TWRN)
>
> On which CPU do you have this problem?
>
on i.MX28.
> Seems that mx25/35 behave a bit different than mx28. But I had no time
> to dig into this, yet. BTW Wolfgang is just reworking error handling,
> can you please test his patches he recently posted on linux-can.
>
The ESR of i.MX25 is completely identical to the i.MX28.
You should be able to reproduce the problem when trying to send a
message to a CAN interface with the transceiver disabled.
You will get a BIT0_ERR and the TWRN bit will be asserted and never
cleared leading to an endless interrupt loop.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [PATCH] flexcan: Acknowledge all interrupt sources in the IRQ handler
From: Wolfgang Grandegger @ 2011-12-09 14:35 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: Marc Kleine-Budde, linux-can, netdev, linux-kernel
In-Reply-To: <20194.5210.650914.867608@ipc1.ka-ro>
On 12/09/2011 02:59 PM, Lothar Waßmann wrote:
> Hi,
>
> Marc Kleine-Budde writes:
>> On 12/09/2011 02:47 PM, Lothar Waßmann wrote:
>>> Otherwise the handler will get stuck in an endless IRQ loop when an
>>> interrupt condition occurs that is not being acked (e.g. TWRN)
>>
>> On which CPU do you have this problem?
>>
> on i.MX28.
Yes, it is definitely needed on i.MX28 and I already have it in my
series. See:
https://gitorious.org/~wgrandegger/linux-can/wg-linux-can-next/commit/8ad94fa0dd7f7728824fa8fd4479390ac3f189c7
BTW: at similar patch was already sent by Reuben Dowle.
>> Seems that mx25/35 behave a bit different than mx28. But I had no time
>> to dig into this, yet. BTW Wolfgang is just reworking error handling,
>> can you please test his patches he recently posted on linux-can.
>>
> The ESR of i.MX25 is completely identical to the i.MX28.
> You should be able to reproduce the problem when trying to send a
> message to a CAN interface with the transceiver disabled.
> You will get a BIT0_ERR and the TWRN bit will be asserted and never
> cleared leading to an endless interrupt loop.
If you are right, the code was never working on i.MX25/35... which I doubt.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v8 1/9] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-12-09 14:37 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, lizf-BthXqXjhjHXQFUHtdCDX3A,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gthelen-hpIqsD4AKlfQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, kirill-oKw7cIdHH8eLwutG50LtGA,
avagin-bzQdu9zFT3WakBO8gow8eQ, devel-GEFAQzZX7r8dnm+yROfE0A,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, hannes-druUgvl0LCNAfugRpC6u6w,
mhocko-AlSwsSmVLrQ, Paul Menage
In-Reply-To: <20111209102113.cdb85da8.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On 12/08/2011 11:21 PM, KAMEZAWA Hiroyuki wrote:
> Hm, why you check val != parent->kmem_independent_accounting ?
>
> if (parent&& parent->use_hierarchy)
> return -EINVAL;
> ?
>
> BTW, you didn't check this cgroup has children or not.
> I think
>
> if (this_cgroup->use_hierarchy&&
> !list_empty(this_cgroup->childlen))
> return -EINVAL;
How about this?
val = !!val;
/*
* This follows the same hierarchy restrictions than
* mem_cgroup_hierarchy_write()
*/
if (!parent || !parent->use_hierarchy) {
if (list_empty(&cgroup->children))
memcg->kmem_independent_accounting = val;
else
return -EBUSY;
}
else
return -EINVAL;
return 0;
--
To unsubscribe from this list: send the line "unsubscribe cgroups" 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: TCP fast retransmit
From: Eric Dumazet @ 2011-12-09 14:43 UTC (permalink / raw)
To: Esztermann, Ansgar; +Cc: netdev@vger.kernel.org
In-Reply-To: <C2C333F1-98FD-41FB-9CFA-EDE9F363CABF@mpi-bpc.mpg.de>
Le vendredi 09 décembre 2011 à 14:34 +0100, Esztermann, Ansgar a écrit :
> On Nov 25, 2011, at 17:36 , Eric Dumazet wrote:
>
> > Could you send a sample pcap of such problem, but please include full
> > tcp sesssion, from the first SYN packet, up to packets following
> > restransmits.
>
> OK, I've got a dump now. It is rather large (>300MB), so it's probably not a good idea to send it to the list. Instead, you can find it here:
> http://wwwuser.gwdg.de/~aeszter/tcpstream.pcap
>
> The capture has been taken in the sender, 10.208.9.87, with a capture filter on the receiver's IP address. OS is:
> % uname -a
> Linux mwolf 2.6.37.6-0.9-default #1 SMP 2011-10-19 22:33:27 +0200 x86_64 x86_64 x86_64 GNU/Linux
>
> The first "strange" retransmission is in frame 166859, following ACKs in frames 166849 .. 166858.
>
> If I can do anything to reduce the amount of data, I will of course do so.
>
> > A diff of "netstat -s" taken before your session and after your session
> > on receiver would help too, if receiver is not a loaded machine of
> > course.
>
> Attached.
>
> Thanks a lot,
>
> A.
>
It seems you have a lot of packet reorders.
Are you using multipath or some channel bonding ?
^ permalink raw reply
* RE: [PATCH v8 1/9] Basic kernel memory functionality for the Memory Controller
From: David Laight @ 2011-12-09 14:44 UTC (permalink / raw)
To: Glauber Costa, KAMEZAWA Hiroyuki
Cc: linux-kernel, lizf, ebiederm, davem, gthelen, netdev, linux-mm,
kirill, avagin, devel, eric.dumazet, cgroups, hannes, mhocko,
Paul Menage
In-Reply-To: <4EE21D23.4000309@parallels.com>
> How about this?
>
> val = !!val;
>
> /*
> * This follows the same hierarchy restrictions than
> * mem_cgroup_hierarchy_write()
> */
> if (!parent || !parent->use_hierarchy) {
> if (list_empty(&cgroup->children))
> memcg->kmem_independent_accounting = val;
> else
> return -EBUSY;
> }
> else
> return -EINVAL;
>
> return 0;
Inverting the tests gives easier to read code:
if (parent && parent->user_hierarchy)
return -EINVAL;
if (!list_empty(&cgroup->children))
return -EBUSY;
memcg->kmem_independent_accounting = val != 0;
return 0;
NFI about the logic...
On the face of it the tests don't seem related to each other
or to the assignment!
David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 1/9] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-12-09 14:48 UTC (permalink / raw)
To: David Laight
Cc: KAMEZAWA Hiroyuki, linux-kernel, lizf, ebiederm, davem, gthelen,
netdev, linux-mm, kirill, avagin, devel, eric.dumazet, cgroups,
hannes, mhocko, Paul Menage
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AF0D@saturn3.aculab.com>
On 12/09/2011 12:44 PM, David Laight wrote:
>
>> How about this?
>>
>> val = !!val;
>>
>> /*
>> * This follows the same hierarchy restrictions than
>> * mem_cgroup_hierarchy_write()
>> */
>> if (!parent || !parent->use_hierarchy) {
>> if (list_empty(&cgroup->children))
>> memcg->kmem_independent_accounting = val;
>> else
>> return -EBUSY;
>> }
>> else
>> return -EINVAL;
>>
>> return 0;
>
> Inverting the tests gives easier to read code:
>
> if (parent&& parent->user_hierarchy)
> return -EINVAL;
> if (!list_empty(&cgroup->children))
> return -EBUSY;
> memcg->kmem_independent_accounting = val != 0;
> return 0;
On the other hand, inconsistent with mem_cgroup_hierarchy_write(), which
applies the logic in the same way I did here.
> NFI about the logic...
> On the face of it the tests don't seem related to each other
> or to the assignment!
How so?
If parent's use_hierarchy is set, we can't set this value (we need to
have a parent for that to even matter).
We also can't set it if we already have any children - otherwise all the
on-the-fly adjustments become hell-on-earth.
As for = val != 0, sorry, but I completely disagree this is easier than
!!val. Not to mention the !!val notation is already pretty widespread in
the kernel.
> David
>
>
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email:<a href=ilto:"dont@kvack.org"> email@kvack.org</a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: flood ping option in iputils has "-w deadline" bug. I have fixed in my copy, I offer to fix the latest code for you.
From: Cloutier, Joseph (Joseph) @ 2011-12-09 14:53 UTC (permalink / raw)
To: 'netdev@vger.kernel.org'
In-Reply-To: <7D3B6706FA74174B8C1AC24710890745136F1A0B8C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
-----Original Message-----
From: Cloutier, Joseph (Joseph)
Sent: Friday, December 09, 2011 9:50 AM
To: 'netdev@vger.kernel.org'
Subject: flood ping option in iputils has "-w deadline" bug. I have
fixed in my copy, I offer to fix the latest code for you.
Joe Cloutier, Alcatel-Lucent, Murray Hill, NJ USA.
Cell Phone USA-973-902-3261.
Thanks, Joe
^ permalink raw reply
* Product Order
From: "SIMKINS LTD" @ 2011-12-09 12:55 UTC (permalink / raw)
To: simkinsltd
Hello,
I am Manager of SIMKINS LTD. USA, My company is interested in the
purchase of your products.
Kindly send me an email with details of:
*Minimum Order Quantity
*Your delivery time
*Payment terms
*And your products warranty
I await to hear from you urgently
Mr Stefan Al Simkins.
Purchasing Manager.
SIMKINS LTD
___________________________________
NOCC, http://nocc.sourceforge.net
^ permalink raw reply
* Testing server performance
From: Igor Maravić @ 2011-12-09 15:26 UTC (permalink / raw)
To: netdev
Hi all,
I'm currently testing how much traffic can I push through my server.
I'm running on Ubuntu 11.10 server with net-next kernel.
I'm using 2 Gbps NICs, Netgear GA311 and D-Link DGE-528T, that use r8169 driver.
I'm generating UDP packets from a router with constant speed.
After I push traffic to my server with max speed, it saturates.
It receives packets at 77MBps and it sends packet with 14MBps.
When there are no incoming traffic, but there are remaining packets in
tx fifo queue, it sends them with 40MBps.
That all wouldn't be strange because my machine isn't any thing special
(AMD Athlon(tm) II X2 240 on 2,8GHz, motherboard ASUS M2N68 PLUS and
2x2GB DDR2 RAM memory on 1066MHz),
but the dstat shows that CPUs are maximally using 6% of their
resources for interrupt handling.
Beside that, nothing else is using CPU time.
Why does it saturate on this values then? Am I doing something wrong?
Any help is appreciated.
BR
Igor
PS. Kernel is SMP enabled and I tried different bit masks for
smp_affinity for my interfaces, but I still got the same result.
^ permalink raw reply
* RE: [PATCH] net/hyperv: Fix the stop/wake queue mechanism
From: Haiyang Zhang @ 2011-12-09 16:00 UTC (permalink / raw)
To: KY Srinivasan, davem@davemloft.net, gregkh@suse.de,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <1322855785-22776-1-git-send-email-haiyangz@microsoft.com>
> -----Original Message-----
> From: Haiyang Zhang [mailto:haiyangz@microsoft.com]
> Sent: Friday, December 02, 2011 2:56 PM
> To: Haiyang Zhang; KY Srinivasan; davem@davemloft.net; gregkh@suse.de;
> linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
> devel@linuxdriverproject.org
> Subject: [PATCH] net/hyperv: Fix the stop/wake queue mechanism
>
> The ring buffer is only used to pass meta data for outbound packets. The
> actual payload is accessed by DMA from the host. So the stop/wake queue
> mechanism based on counting and comparing number of pages sent v.s.
> number
> of pages in the ring buffer is wrong. Also, there is a race condition in
> the stop/wake queue calls, which can stop xmit queue forever.
>
> The new stop/wake queue mechanism is based on the actual bytes used by
> outbound packets in the ring buffer. The check for number of outstanding
> sends after stop queue prevents the race condition that can cause wake
> queue happening earlier than stop queue.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Reported-by: Long Li <longli@microsoft.com>
> ---
> drivers/net/hyperv/netvsc.c | 14 +++++++++++---
> drivers/net/hyperv/netvsc_drv.c | 24 +-----------------------
> 2 files changed, 12 insertions(+), 26 deletions(-)
Hi Greg,
Since the netvsc haven't been merged into Dave's tree yet after out of staging,
could you consider this patch for your tree?
Thanks,
- Haiyang
^ permalink raw reply
* Re: [net-next PATCH] net: netprio_cgroup: make net_prio_subsys static
From: Eric Dumazet @ 2011-12-09 16:05 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, john.r.fastabend, netdev
In-Reply-To: <20111208.195339.152346047030004418.davem@davemloft.net>
Le jeudi 08 décembre 2011 à 19:53 -0500, David Miller a écrit :
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Thu, 8 Dec 2011 06:45:55 -0500
>
> > On Wed, Dec 07, 2011 at 09:17:17PM -0800, John Fastabend wrote:
> >> net_prio_subsys can be made static this removes the sparse
> >> warning it was throwing.
> >>
> >> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ...
> > Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
> Applied.
> --
But it trivialy breaks the build ? Or am I mistaken ?
$ grep CONFIG_NETPRIO_CGROUP .config
CONFIG_NETPRIO_CGROUP=y
$ make net/core/netprio_cgroup.o
CC net/core/netprio_cgroup.o
net/core/netprio_cgroup.c:31:29: error: static declaration of ‘net_prio_subsys’ follows non-static declaration
include/linux/cgroup_subsys.h:71:1: note: previous declaration of ‘net_prio_subsys’ was here
make[1]: *** [net/core/netprio_cgroup.o] Error 1
make: *** [net/core/netprio_cgroup.o] Error 2
^ permalink raw reply
* Re: TCP fast retransmit
From: Esztermann, Ansgar @ 2011-12-09 16:17 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <1323441811.2336.18.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Dec 9, 2011, at 15:43 , Eric Dumazet wrote:
> It seems you have a lot of packet reorders.
>
> Are you using multipath or some channel bonding ?
Not that I am aware of (i.e. not on our end). However, the connection will probably routed through a firewall. I will have to check if it is configured to avoid reordering.
Regards,
A.
--
Ansgar Esztermann
DV-Systemadministration
Max-Planck-Institut für biophysikalische Chemie, Abteilung 105
^ permalink raw reply
* [PATCH 0/13] Implement dumping udp sockets via sock_diag netlink
From: Pavel Emelyanov @ 2011-12-09 16:20 UTC (permalink / raw)
To: David Miller, Linux Netdev List
Hi!
This is an extension of inet_diag module and the new udp_diag one. Plus
the patch for iproute's ss to dump udp sockets via netlink (applies on top
of previous patch for new NETLINK_SOCK_DIAG API [1]).
The overall idea is:
Patch the inet_diag module so that the protocol level handlers are called
indirectly from the very beginning, not just for getting the tcp_info bits.
Implement the udp_diag module that provides callbacks for IPPROTO_UDP and
IPPROTO_UDPLITE protocols.
The existing inet request packet (inet_diag_req) format used to request for
TCP/DCCP sockets is used for UDP socket as well, although not all the state
bits matter for UDP.
When sending back the reply the existing format (inet_diag_message) is used
as well. Some bits on this struct are meaningless for UDP, but I hope that
setting these to 0 and wasting some space on reply skb worth the saved amount
of new code on both -- the kernel side and the userspace side (i.e. ss tool).
The data that is stored in an nl attribute but doesn't exist for UDP is just
not provided.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
[1] http://www.spinics.net/lists/netdev/msg182467.html
^ permalink raw reply
* [PATCH 1/13] inet_diag: Remove indirect sizeof from inet diag handlers
From: Pavel Emelyanov @ 2011-12-09 16:21 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE23561.5020804@parallels.com>
There's an info_size value stored on inet_diag_handler, but for existing
code this value is effectively constant, so just use sizeof(struct tcp_info)
where required.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/linux/inet_diag.h | 1 -
net/dccp/diag.c | 1 -
net/ipv4/inet_diag.c | 5 ++---
net/ipv4/tcp_diag.c | 1 -
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
index defe8ff..851feff 100644
--- a/include/linux/inet_diag.h
+++ b/include/linux/inet_diag.h
@@ -141,7 +141,6 @@ struct inet_diag_handler {
void (*idiag_get_info)(struct sock *sk,
struct inet_diag_msg *r,
void *info);
- __u16 idiag_info_size;
__u16 idiag_type;
};
diff --git a/net/dccp/diag.c b/net/dccp/diag.c
index 424dcd8..9343f52 100644
--- a/net/dccp/diag.c
+++ b/net/dccp/diag.c
@@ -52,7 +52,6 @@ static const struct inet_diag_handler dccp_diag_handler = {
.idiag_hashinfo = &dccp_hashinfo,
.idiag_get_info = dccp_diag_get_info,
.idiag_type = IPPROTO_DCCP,
- .idiag_info_size = sizeof(struct tcp_info),
};
static int __init dccp_diag_init(void)
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index b56b7ba..a247f85 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -98,8 +98,7 @@ static int inet_csk_diag_fill(struct sock *sk,
minfo = INET_DIAG_PUT(skb, INET_DIAG_MEMINFO, sizeof(*minfo));
if (ext & (1 << (INET_DIAG_INFO - 1)))
- info = INET_DIAG_PUT(skb, INET_DIAG_INFO,
- handler->idiag_info_size);
+ info = INET_DIAG_PUT(skb, INET_DIAG_INFO, sizeof(struct tcp_info));
if ((ext & (1 << (INET_DIAG_CONG - 1))) && icsk->icsk_ca_ops) {
const size_t len = strlen(icsk->icsk_ca_ops->name);
@@ -299,7 +298,7 @@ static int inet_diag_get_exact(struct sk_buff *in_skb,
err = -ENOMEM;
rep = alloc_skb(NLMSG_SPACE((sizeof(struct inet_diag_msg) +
sizeof(struct inet_diag_meminfo) +
- handler->idiag_info_size + 64)),
+ sizeof(struct tcp_info) + 64)),
GFP_KERNEL);
if (!rep)
goto out;
diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c
index 9814977..42e6bec 100644
--- a/net/ipv4/tcp_diag.c
+++ b/net/ipv4/tcp_diag.c
@@ -38,7 +38,6 @@ static const struct inet_diag_handler tcp_diag_handler = {
.idiag_hashinfo = &tcp_hashinfo,
.idiag_get_info = tcp_diag_get_info,
.idiag_type = IPPROTO_TCP,
- .idiag_info_size = sizeof(struct tcp_info),
};
static int __init tcp_diag_init(void)
--
1.5.5.6
^ permalink raw reply related
* [PATCH 2/13] inet_diag: Reduce the number of args for bytecode run routine
From: Pavel Emelyanov @ 2011-12-09 16:21 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE23561.5020804@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
net/ipv4/inet_diag.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index a247f85..bd3f661 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -355,9 +355,12 @@ static int bitstring_match(const __be32 *a1, const __be32 *a2, int bits)
}
-static int inet_diag_bc_run(const void *bc, int len,
- const struct inet_diag_entry *entry)
+static int inet_diag_bc_run(const struct nlattr *_bc,
+ const struct inet_diag_entry *entry)
{
+ const void *bc = nla_data(_bc);
+ int len = nla_len(_bc);
+
while (len > 0) {
int yes = 1;
const struct inet_diag_bc_op *op = bc;
@@ -512,7 +515,7 @@ static int inet_csk_diag_dump(struct sock *sk,
entry.dport = ntohs(inet->inet_dport);
entry.userlocks = sk->sk_userlocks;
- if (!inet_diag_bc_run(nla_data(bc), nla_len(bc), &entry))
+ if (!inet_diag_bc_run(bc, &entry))
return 0;
}
@@ -547,7 +550,7 @@ static int inet_twsk_diag_dump(struct inet_timewait_sock *tw,
entry.dport = ntohs(tw->tw_dport);
entry.userlocks = 0;
- if (!inet_diag_bc_run(nla_data(bc), nla_len(bc), &entry))
+ if (!inet_diag_bc_run(bc, &entry))
return 0;
}
@@ -668,8 +671,7 @@ static int inet_diag_dump_reqs(struct sk_buff *skb, struct sock *sk,
&ireq->rmt_addr;
entry.dport = ntohs(ireq->rmt_port);
- if (!inet_diag_bc_run(nla_data(bc),
- nla_len(bc), &entry))
+ if (!inet_diag_bc_run(bc, &entry))
continue;
}
--
1.5.5.6
^ permalink raw reply related
* [PATCH 3/13] inet_diag: Export inet diag cookie checking routine
From: Pavel Emelyanov @ 2011-12-09 16:21 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE23561.5020804@parallels.com>
The netlink diag susbsys stores sk address bits in the nl message
as a "cookie" and uses one when dumps details about particular
socket.
The same will be required for udp diag module, so introduce a heler
in inet_diag module
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/linux/inet_diag.h | 2 ++
net/ipv4/inet_diag.c | 19 ++++++++++++++-----
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
index 851feff..5036747 100644
--- a/include/linux/inet_diag.h
+++ b/include/linux/inet_diag.h
@@ -144,6 +144,8 @@ struct inet_diag_handler {
__u16 idiag_type;
};
+int inet_diag_check_cookie(struct sock *sk, struct inet_diag_req *req);
+
extern int inet_diag_register(const struct inet_diag_handler *handler);
extern void inet_diag_unregister(const struct inet_diag_handler *handler);
#endif /* __KERNEL__ */
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index bd3f661..ba3ae1f 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -246,6 +246,18 @@ static int sk_diag_fill(struct sock *sk, struct sk_buff *skb,
return inet_csk_diag_fill(sk, skb, r, pid, seq, nlmsg_flags, unlh);
}
+int inet_diag_check_cookie(struct sock *sk, struct inet_diag_req *req)
+{
+ if ((req->id.idiag_cookie[0] != INET_DIAG_NOCOOKIE ||
+ req->id.idiag_cookie[1] != INET_DIAG_NOCOOKIE) &&
+ ((u32)(unsigned long)sk != req->id.idiag_cookie[0] ||
+ (u32)((((unsigned long)sk) >> 31) >> 1) != req->id.idiag_cookie[1]))
+ return -ESTALE;
+ else
+ return 0;
+}
+EXPORT_SYMBOL_GPL(inet_diag_check_cookie);
+
static int inet_diag_get_exact(struct sk_buff *in_skb,
const struct nlmsghdr *nlh,
struct inet_diag_req *req)
@@ -288,11 +300,8 @@ static int inet_diag_get_exact(struct sk_buff *in_skb,
if (sk == NULL)
goto unlock;
- err = -ESTALE;
- if ((req->id.idiag_cookie[0] != INET_DIAG_NOCOOKIE ||
- req->id.idiag_cookie[1] != INET_DIAG_NOCOOKIE) &&
- ((u32)(unsigned long)sk != req->id.idiag_cookie[0] ||
- (u32)((((unsigned long)sk) >> 31) >> 1) != req->id.idiag_cookie[1]))
+ err = inet_diag_check_cookie(sk, req);
+ if (err)
goto out;
err = -ENOMEM;
--
1.5.5.6
^ permalink raw reply related
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