* Re: MTU and TCP transmit offload.
From: Rick Jones @ 2011-09-21 22:11 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E7A51EE.8010403@candelatech.com>
On 09/21/2011 02:06 PM, Ben Greear wrote:
> We saw something interesting while doing some testing
> on 3.0.4.
>
> We configured 2 Ethernet NICs with standard 1500 MTU, and added
> a mac-vlan on each, with MTU of 300. The goal was to generate as
> many ~300 byte TCP packets as possible, for load testing purposes.
> We configured our tool to open sockets on the mac-vlans and send/receive
> TCP (IPv4) traffic.
Presumably one could instead set static PathMTU entries in the routing
tables and accomplish the same thing as you did with the mac-vlans?
> This actually seems to work quite nicely, allowing user-space to
> do large writes (24k in our case), and it appears have lots of
> small packets on the wire. We still need to sniff with external
> system to verify this..but packets-per-second counters look good.
>
> Evidently this all works because macvlans know that the NIC
> can do TSO, and the '300' MTU is passed in the big packet
> given to the NIC.
>
> This got me thinking...at least for my purposes, it would be
> nice to have a per-socket 'MTU' setting. The idea is that
> you could ask the NIC to do the TSO at whatever 'mtu' you
> wanted, without having to resort to mac-vlans with artificially
> small MTU.
>
> So, is there any interest in supporting such a socket option?
>
> I can't think of any use besides TCP traffic load testing, but
> perhaps someone else can think of one? Or, is load-testing
> enough?
Isn't that covered by setsockopt() support for TCP_MAX_SEG? With TSO
what gets passed to the NIC isn't the MTU, but the connection's MSS
derived (in part at least) from the MTU of the egress interface. If one
had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or
listen() call, presumably that would have influenced the MSS exchange at
connection establishment.
rick jones
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Ben Greear @ 2011-09-21 22:16 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4E7A612C.9090508@hp.com>
On 09/21/2011 03:11 PM, Rick Jones wrote:
> On 09/21/2011 02:06 PM, Ben Greear wrote:
>> We saw something interesting while doing some testing
>> on 3.0.4.
>>
>> We configured 2 Ethernet NICs with standard 1500 MTU, and added
>> a mac-vlan on each, with MTU of 300. The goal was to generate as
>> many ~300 byte TCP packets as possible, for load testing purposes.
>> We configured our tool to open sockets on the mac-vlans and send/receive
>> TCP (IPv4) traffic.
>
> Presumably one could instead set static PathMTU entries in the routing tables and accomplish the same thing as you did with the mac-vlans?
>
>> This actually seems to work quite nicely, allowing user-space to
>> do large writes (24k in our case), and it appears have lots of
>> small packets on the wire. We still need to sniff with external
>> system to verify this..but packets-per-second counters look good.
>>
>> Evidently this all works because macvlans know that the NIC
>> can do TSO, and the '300' MTU is passed in the big packet
>> given to the NIC.
>>
>> This got me thinking...at least for my purposes, it would be
>> nice to have a per-socket 'MTU' setting. The idea is that
>> you could ask the NIC to do the TSO at whatever 'mtu' you
>> wanted, without having to resort to mac-vlans with artificially
>> small MTU.
>>
>> So, is there any interest in supporting such a socket option?
>>
>> I can't think of any use besides TCP traffic load testing, but
>> perhaps someone else can think of one? Or, is load-testing
>> enough?
>
> Isn't that covered by setsockopt() support for TCP_MAX_SEG? With TSO what gets passed to the NIC isn't the MTU, but the connection's MSS derived (in part at
> least) from the MTU of the egress interface. If one had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or listen() call, presumably that would have
> influenced the MSS exchange at connection establishment.
Ohh, that looks promising!
I'll give that a try.
Thanks,
Ben
>
> rick jones
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: Marek Lindner @ 2011-09-21 23:39 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20110921.152616.1053525623924985457.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wednesday, September 21, 2011 21:26:16 David Miller wrote:
> > are available in the git repository at:
> > git://git.open-mesh.org/linux-merge.git batman-adv/next
>
> Pulled, thanks Marek.
Pretty sure you are quite busy fighting with your backlog of patches but would
you mind giving some advice on this:
To ensure a smooth transition and efficient testing later, we
decided to offer a choice of routing algorithm but have not
come to a final decision on how to design this choice yet. It
either will be a compile time option, a module parameter or a
runtime switch. Any suggestions / best practice tips ?
Regards,
Marek
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Ben Greear @ 2011-09-21 23:42 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4E7A6225.8040902@candelatech.com>
On 09/21/2011 03:16 PM, Ben Greear wrote:
> On 09/21/2011 03:11 PM, Rick Jones wrote:
>> On 09/21/2011 02:06 PM, Ben Greear wrote:
>>> We saw something interesting while doing some testing
>>> on 3.0.4.
>>>
>>> We configured 2 Ethernet NICs with standard 1500 MTU, and added
>>> a mac-vlan on each, with MTU of 300. The goal was to generate as
>>> many ~300 byte TCP packets as possible, for load testing purposes.
>>> We configured our tool to open sockets on the mac-vlans and send/receive
>>> TCP (IPv4) traffic.
>>
>> Presumably one could instead set static PathMTU entries in the routing tables and accomplish the same thing as you did with the mac-vlans?
>>
>>> This actually seems to work quite nicely, allowing user-space to
>>> do large writes (24k in our case), and it appears have lots of
>>> small packets on the wire. We still need to sniff with external
>>> system to verify this..but packets-per-second counters look good.
>>>
>>> Evidently this all works because macvlans know that the NIC
>>> can do TSO, and the '300' MTU is passed in the big packet
>>> given to the NIC.
>>>
>>> This got me thinking...at least for my purposes, it would be
>>> nice to have a per-socket 'MTU' setting. The idea is that
>>> you could ask the NIC to do the TSO at whatever 'mtu' you
>>> wanted, without having to resort to mac-vlans with artificially
>>> small MTU.
>>>
>>> So, is there any interest in supporting such a socket option?
>>>
>>> I can't think of any use besides TCP traffic load testing, but
>>> perhaps someone else can think of one? Or, is load-testing
>>> enough?
>>
>> Isn't that covered by setsockopt() support for TCP_MAX_SEG? With TSO what gets passed to the NIC isn't the MTU, but the connection's MSS derived (in part at
>> least) from the MTU of the egress interface. If one had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or listen() call, presumably that would have
>> influenced the MSS exchange at connection establishment.
>
> Ohh, that looks promising!
>
> I'll give that a try.
This works like a charm. I'm so glad I don't need to hack
a new sockopt!
Thanks,
Ben
>
> Thanks,
> Ben
>
>>
>> rick jones
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: MTU and TCP transmit offload.
From: Rick Jones @ 2011-09-21 23:58 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4E7A765E.6020701@candelatech.com>
>>> Isn't that covered by setsockopt() support for TCP_MAX_SEG? With
>>> TSO what gets passed to the NIC isn't the MTU, but the
>>> connection's MSS derived (in part at least) from the MTU of the
>>> egress interface. If one had made a setsockopt(TCP_MAX_SEG) call
>>> prior to the connect() or listen() call, presumably that would
>>> have influenced the MSS exchange at connection establishment.
>>
>> Ohh, that looks promising!
>>
>> I'll give that a try.
>
> This works like a charm. I'm so glad I don't need to hack
> a new sockopt!
Glad it works for you.
happy benchmarking,
rick jones
One of these days I'll have to decide if I add that as an option to
netperf, which presently only does the getsockopt(TCP_MAX_SEG). Folks
with a strong preference one way or t'other should feel free to contact
me on the side or via netperf-talk at netperf.org.
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: David Miller @ 2011-09-22 0:05 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <201109220139.26897.lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Thu, 22 Sep 2011 01:39:26 +0200
> To ensure a smooth transition and efficient testing later, we
> decided to offer a choice of routing algorithm but have not
> come to a final decision on how to design this choice yet. It
> either will be a compile time option, a module parameter or a
> runtime switch. Any suggestions / best practice tips ?
What do you mean by "algorithm"? Do you mean the implementation
of the data-structure used to perform lookups?
We had two data structures for our main routing table lookup
implementation in ipv4, this was a mistake. We spent the next couple
years maintaining two pieces of code, and finally investing lots of
effort to eliminate the older code.
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: Marek Lindner @ 2011-09-22 0:10 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20110921.200539.1422752575190292433.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thursday, September 22, 2011 02:05:39 David Miller wrote:
> From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
> Date: Thu, 22 Sep 2011 01:39:26 +0200
>
> > To ensure a smooth transition and efficient testing later, we
> > decided to offer a choice of routing algorithm but have not
> > come to a final decision on how to design this choice yet. It
> > either will be a compile time option, a module parameter or a
> > runtime switch. Any suggestions / best practice tips ?
>
> What do you mean by "algorithm"? Do you mean the implementation
> of the data-structure used to perform lookups?
>
> We had two data structures for our main routing table lookup
> implementation in ipv4, this was a mistake. We spent the next couple
> years maintaining two pieces of code, and finally investing lots of
> effort to eliminate the older code.
No, the data structures for the routing lookups remain the same but there will
be more than one way to fill them with data. You will only use one "filling
algorithm" at a time, so you will need to select the one you want.
Regards,
Marek
^ permalink raw reply
* Re: [B.A.T.M.A.N.] pull request: batman-adv 2011-09-08
From: David Miller @ 2011-09-22 0:11 UTC (permalink / raw)
To: lindner_marek; +Cc: b.a.t.m.a.n, netdev
In-Reply-To: <201109220210.05025.lindner_marek@yahoo.de>
From: Marek Lindner <lindner_marek@yahoo.de>
Date: Thu, 22 Sep 2011 02:10:04 +0200
> No, the data structures for the routing lookups remain the same but there will
> be more than one way to fill them with data. You will only use one "filling
> algorithm" at a time, so you will need to select the one you want.
Extend the userspace interface for adding route entries with a boolean
flag. You're using netlink right? If so, this should be trivial by
simply adding a flags attribute if you don't have one already.
^ permalink raw reply
* [net-next 1/1] bna: PCI Probe Conf Lock Fix
From: Rasesh Mody @ 2011-09-22 0:31 UTC (permalink / raw)
To: netdev; +Cc: dan.carpenter, adapter_linux_open_src_team, Rasesh Mody
If register_netdev() fails now, then we call mutex_unlock(&bnad->conf_mutex);
on the error path, but it's already unlocked. So we acquire the lock in error
path which will be later unlocked after the cleanup.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index abca139..db6c097 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3359,6 +3359,7 @@ probe_success:
return 0;
probe_uninit:
+ mutex_lock(&bnad->conf_mutex);
bnad_res_free(bnad, &bnad->mod_res_info[0], BNA_MOD_RES_T_MAX);
disable_ioceth:
bnad_ioceth_disable(bnad);
--
1.7.1
^ permalink raw reply related
* RE: bna: PCI Probe Fix
From: Rasesh Mody @ 2011-09-22 0:32 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110920084721.GA8441@elgon.mountain>
>From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
>Sent: Tuesday, September 20, 2011 1:47 AM
>
>There is a problem introduced in 0caa9aaec5 "bna: PCI Probe Fix".
>
>If register_netdev() fails now, then we call mutex_unlock(&bnad-
>>conf_mutex);
>on the error path, but it's already unlocked.
Thanks Dan!
Sent a fix so that we acquire the lock in error path which will be later unlocked after the cleanup.
Regards,
Rasesh
^ permalink raw reply
* File Your CLaims
From: BMW GROUP @ 2011-09-22 0:12 UTC (permalink / raw)
Your E-mail Have 750,000.00GBP And a brand new BMW X6 35iM, M Sport Saloon car. Please
contact Us for more-details.(Email:wu-claimsdept@w.cn ).Send your name / address / age /
country.
^ permalink raw reply
* Re: [net-next 1/1] bna: PCI Probe Conf Lock Fix
From: David Miller @ 2011-09-22 0:42 UTC (permalink / raw)
To: rmody; +Cc: netdev, dan.carpenter, adapter_linux_open_src_team
In-Reply-To: <1316651510-19646-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Wed, 21 Sep 2011 17:31:50 -0700
> If register_netdev() fails now, then we call mutex_unlock(&bnad->conf_mutex);
> on the error path, but it's already unlocked. So we acquire the lock in error
> path which will be later unlocked after the cleanup.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Applied, but I had to add:
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Please don't leave out bug reporter credit like this.
^ permalink raw reply
* RE: [net-next 1/1] bna: PCI Probe Conf Lock Fix
From: Rasesh Mody @ 2011-09-22 0:54 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, dan.carpenter@oracle.com,
adapter_linux_open_src_team@blc-10-4.brocade.com
In-Reply-To: <20110921.204200.1913137093700457756.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, September 21, 2011 5:42 PM
>
>Applied, but I had to add:
>
>Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
>Please don't leave out bug reporter credit like this.
Thanks for doing it this time, we'll take care of adding the bug reporter in future.
^ permalink raw reply
* I Need Your Assistance
From: Mr Ahmed Hassan @ 2011-09-22 0:54 UTC (permalink / raw)
Dear Beloved,
I Mr Ahmed Hassan,a Business merchant who is diagnosed with
"Esophageal Cancer"
which
defiled all forms of medical treatment and i have cash deposit of Twenty One
million dollars ($21,000,000,00) that I have with a finance Company abroad,i
need someone to stand as a benefactor,if you are interested indicate your
interest.and i will give you the full details
^ permalink raw reply
* dccp test-tree [ANNOUNCE] dccp: DCCP-Cubic / CCID-5 subtree available
From: Gerrit Renker @ 2011-09-22 2:50 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev, percomp-pos
Thanks to Ivo for implementing DCCP-Cubic (aka CCID-249, aka CCID-5).
I have added a new subtree for CCID-249 at
git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree `ccid5']
Patch based on net-2.6 is at
http://eden-feed.erg.abdn.ac.uk/latest-dccp-ccid5-test-tree.diff.gz
Tarball based on net-2.6 is at
http://eden-feed.erg.abdn.ac.uk/latest-dccp-ccid5-test-tree.tar.bz2
after fixing some whitespace issues in the patch. I will keep it in synch
with the rest of the test tree, please do send any updates you find for CCID-5.
==========================================
Short HOWTO on installing and using CCID-5
==========================================
To clone the ccid5 tree,
git checkout -b ccid5
git pull git://eden-feed.erg.abdn.ac.uk/dccp_exp +ccid5:ccid5
When recompiling the dccp module, set
CONFIG_IP_DCCP_CCID5=y
CONFIG_IP_DCCP_CCID5_DEBUG=y
After installation and modprobing the dccp module, set
echo 249 > /proc/sys/net/dccp/default/tx_ccid
echo 249 > /proc/sys/net/dccp/default/rx_ccid
to use the CCID-5 (resp. CCID-249) module.
On 1Gbit ethernet, I measured up to 776 Mbps with iperf,
on a noisy 2.4Ghz 802.11g it was still 13.7 Mbps.
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Balbir Singh @ 2011-09-22 3:17 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, Ying Han
In-Reply-To: <4E794AA2.9080008@parallels.com>
On Wed, Sep 21, 2011 at 7:53 AM, Glauber Costa <glommer@parallels.com> wrote:
>
> Hi people,
>
> Any insights on this series?
> Kame, is it inline with your expectations ?
>
> Thank you all
>
> On 09/18/2011 09:56 PM, Glauber Costa 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@parallels.com>
>> CC: Paul Menage<paul@paulmenage.org>
>> CC: Greg Thelen<gthelen@google.com>
>> ---
>> Documentation/cgroups/memory.txt | 30 +++++++++-
>> init/Kconfig | 11 ++++
>> mm/memcontrol.c | 115 ++++++++++++++++++++++++++++++++++++--
>> 3 files changed, 148 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index 6f3c598..6f1954a 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
>> @@ -44,8 +44,9 @@ Features:
>> - oom-killer disable knob and oom-notifier
>> - Root cgroup has no limit controls.
>>
>> - Kernel memory and Hugepages are not under control yet. We just manage
>> - pages on LRU. To add more controls, we have to take care of performance.
>> + Hugepages is not under control yet. We just manage pages on LRU. To add more
>> + controls, we have to take care of performance. Kernel memory support is work
>> + in progress, and the current version provides basically functionality.
>>
>> Brief summary of control files.
>>
>> @@ -56,8 +57,11 @@ Brief summary of control files.
>> (See 5.5 for details)
>> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
>> (See 5.5 for details)
>> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
>> + (See 2.7 for details)
>> memory.limit_in_bytes # set/show limit of memory usage
>> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
>> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
>> memory.failcnt # show the number of memory usage hits limits
>> memory.memsw.failcnt # show the number of memory+Swap hits limits
>> memory.max_usage_in_bytes # show max memory usage recorded
>> @@ -72,6 +76,9 @@ Brief summary of control files.
>> memory.oom_control # set/show oom controls.
>> memory.numa_stat # show the number of memory usage per numa node
>>
>> + memory.independent_kmem_limit # select whether or not kernel memory limits are
>> + independent of user limits
>> +
>> 1. History
>>
>> The memory controller has a long history. A request for comments for the memory
>> @@ -255,6 +262,25 @@ When oom event notifier is registered, event will be delivered.
>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>> zone->lru_lock, it has no lock of its own.
>>
>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>> +
>> + With the Kernel memory extension, the Memory Controller is able to limit
>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>> +different than user memory, since it can't be swapped out, which makes it
>> +possible to DoS the system by consuming too much of this precious resource.
>> +Kernel memory limits are not imposed for the root cgroup.
>> +
>> +Memory limits as specified by the standard Memory Controller may or may not
>> +take kernel memory into consideration. This is achieved through the file
>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>> +memory to be controlled separately.
>> +
>> +When kernel memory limits are not independent, the limit values set in
>> +memory.kmem files are ignored.
>> +
>> +Currently no soft limit is implemented for kernel memory. It is future work
>> +to trigger slab reclaim when those limits are reached.
>> +
Ying Han was also looking into this (cc'ing her)
>> 3. User Interface
>>
>> 0. Configuration
>> diff --git a/init/Kconfig b/init/Kconfig
>> index d627783..49e5839 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
>> For those who want to have the feature enabled by default should
>> select this option (if, for some reason, they need to disable it
>> then swapaccount=0 does the trick).
>> +config CGROUP_MEM_RES_CTLR_KMEM
>> + bool "Memory Resource Controller Kernel Memory accounting"
>> + depends on CGROUP_MEM_RES_CTLR
>> + default y
>> + help
>> + The Kernel Memory extension for Memory Resource Controller can limit
>> + the amount of memory used by kernel objects in the system. Those are
>> + fundamentally different from the entities handled by the standard
>> + Memory Controller, which are page-based, and can be swapped. Users of
>> + the kmem extension can use it to guarantee that no group of processes
>> + will ever exhaust kernel resources alone.
>>
>> config CGROUP_PERF
>> bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index ebd1e86..d32e931 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
>> #define do_swap_account (0)
>> #endif
>>
>> -
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int do_kmem_account __read_mostly = 1;
>> +#else
>> +#define do_kmem_account 0
>> +#endif
>> /*
>> * Statistics for memory cgroup.
>> */
>> @@ -270,6 +274,10 @@ struct mem_cgroup {
>> */
>> struct res_counter memsw;
>> /*
>> + * the counter to account for kmem usage.
>> + */
>> + struct res_counter kmem;
>> + /*
>> * Per cgroup active and inactive list, similar to the
>> * per zone LRU lists.
>> */
>> @@ -321,6 +329,11 @@ struct mem_cgroup {
>> */
>> unsigned long move_charge_at_immigrate;
>> /*
>> + * Should kernel memory limits be stabilished independently
>> + * from user memory ?
>> + */
>> + int kmem_independent;
>> + /*
>> * percpu counter.
>> */
>> struct mem_cgroup_stat_cpu *stat;
>> @@ -388,9 +401,14 @@ enum charge_type {
>> };
>>
>> /* for encoding cft->private value on file */
>> -#define _MEM (0)
>> -#define _MEMSWAP (1)
>> -#define _OOM_TYPE (2)
>> +
>> +enum mem_type {
>> + _MEM = 0,
>> + _MEMSWAP,
>> + _OOM_TYPE,
>> + _KMEM,
>> +};
>> +
>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
>> u64 val;
>>
>> if (!mem_cgroup_is_root(mem)) {
>> + val = 0;
>> + if (!mem->kmem_independent)
>> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
>> if (!swap)
>> - return res_counter_read_u64(&mem->res, RES_USAGE);
>> + val += res_counter_read_u64(&mem->res, RES_USAGE);
>> else
>> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
>> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
>> +
>> + return val;
>> }
>>
>> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
>> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>> else
>> val = res_counter_read_u64(&mem->memsw, name);
>> break;
>> + case _KMEM:
>> + val = res_counter_read_u64(&mem->kmem, name);
>> + break;
>> +
>> default:
>> BUG();
>> break;
>> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
>> +{
>> + return mem_cgroup_from_cont(cont)->kmem_independent;
>> +}
>> +
>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>> + u64 val)
>> +{
>> + cgroup_lock();
>> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
>> + cgroup_unlock();
>> + return 0;
>> +}
I know we have a lot of pending xxx_from_cont() and struct cgroup
*cont, can we move it to memcg notation to be more consistent with our
usage. There is a patch to convert old usage
>> +#endif
>>
>> static struct cftype mem_cgroup_files[] = {
>> {
>> @@ -4877,6 +4919,47 @@ static int register_memsw_files(struct cgroup *cont, struct cgroup_subsys *ss)
>> }
>> #endif
>>
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static struct cftype kmem_cgroup_files[] = {
>> + {
>> + .name = "independent_kmem_limit",
>> + .read_u64 = kmem_limit_independent_read,
>> + .write_u64 = kmem_limit_independent_write,
>> + },
>> + {
>> + .name = "kmem.usage_in_bytes",
>> + .private = MEMFILE_PRIVATE(_KMEM, RES_USAGE),
>> + .read_u64 = mem_cgroup_read,
>> + },
>> + {
>> + .name = "kmem.limit_in_bytes",
>> + .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT),
>> + .read_u64 = mem_cgroup_read,
>> + },
>> +};
>> +
>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>> +{
>> + struct mem_cgroup *mem = mem_cgroup_from_cont(cont);
>> + int ret = 0;
>> +
>> + if (!do_kmem_account)
>> + return 0;
>> +
>> + if (!mem_cgroup_is_root(mem))
>> + ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>> + ARRAY_SIZE(kmem_cgroup_files));
>> + return ret;
>> +};
>> +
>> +#else
>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
>> {
>> struct mem_cgroup_per_node *pn;
>> @@ -5075,6 +5158,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>> if (parent&& parent->use_hierarchy) {
>> res_counter_init(&mem->res,&parent->res);
>> res_counter_init(&mem->memsw,&parent->memsw);
>> + res_counter_init(&mem->kmem,&parent->kmem);
>> /*
>> * We increment refcnt of the parent to ensure that we can
>> * safely access it on res_counter_charge/uncharge.
>> @@ -5085,6 +5169,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>> } else {
>> res_counter_init(&mem->res, NULL);
>> res_counter_init(&mem->memsw, NULL);
>> + res_counter_init(&mem->kmem, NULL);
>> }
>> mem->last_scanned_child = 0;
>> mem->last_scanned_node = MAX_NUMNODES;
>> @@ -5129,6 +5214,10 @@ static int mem_cgroup_populate(struct cgroup_subsys *ss,
>>
>> if (!ret)
>> ret = register_memsw_files(cont, ss);
>> +
>> + if (!ret)
>> + ret = register_kmem_files(cont, ss);
>> +
>> return ret;
>> }
>>
>> @@ -5665,3 +5754,17 @@ static int __init enable_swap_account(char *s)
>> __setup("swapaccount=", enable_swap_account);
>>
>> #endif
>> +
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static int __init disable_kmem_account(char *s)
>> +{
>> + /* consider enabled if no parameter or 1 is given */
>> + if (!strcmp(s, "1"))
>> + do_kmem_account = 1;
>> + else if (!strcmp(s, "0"))
>> + do_kmem_account = 0;
>> + return 1;
>> +}
>> +__setup("kmemaccount=", disable_kmem_account);
>> +
>> +#endif
The infrastructure looks OK, we need better integration with
statistics for kmem usage.
Balbir Singh
--
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 v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-22 3:19 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, Ying Han
In-Reply-To: <CAKTCnzmkuL+9ftD5d0Z8b5w+DUSUoLiWqSX_TgGxtRxtoPsxpA@mail.gmail.com>
On 09/22/2011 12:17 AM, Balbir Singh wrote:
> On Wed, Sep 21, 2011 at 7:53 AM, Glauber Costa<glommer@parallels.com> wrote:
>>
>> Hi people,
>>
>> Any insights on this series?
>> Kame, is it inline with your expectations ?
>>
>> Thank you all
>>
>> On 09/18/2011 09:56 PM, Glauber Costa 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@parallels.com>
>>> CC: Paul Menage<paul@paulmenage.org>
>>> CC: Greg Thelen<gthelen@google.com>
>>> ---
>>> Documentation/cgroups/memory.txt | 30 +++++++++-
>>> init/Kconfig | 11 ++++
>>> mm/memcontrol.c | 115 ++++++++++++++++++++++++++++++++++++--
>>> 3 files changed, 148 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>>> index 6f3c598..6f1954a 100644
>>> --- a/Documentation/cgroups/memory.txt
>>> +++ b/Documentation/cgroups/memory.txt
>>> @@ -44,8 +44,9 @@ Features:
>>> - oom-killer disable knob and oom-notifier
>>> - Root cgroup has no limit controls.
>>>
>>> - Kernel memory and Hugepages are not under control yet. We just manage
>>> - pages on LRU. To add more controls, we have to take care of performance.
>>> + Hugepages is not under control yet. We just manage pages on LRU. To add more
>>> + controls, we have to take care of performance. Kernel memory support is work
>>> + in progress, and the current version provides basically functionality.
>>>
>>> Brief summary of control files.
>>>
>>> @@ -56,8 +57,11 @@ Brief summary of control files.
>>> (See 5.5 for details)
>>> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
>>> (See 5.5 for details)
>>> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
>>> + (See 2.7 for details)
>>> memory.limit_in_bytes # set/show limit of memory usage
>>> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
>>> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
>>> memory.failcnt # show the number of memory usage hits limits
>>> memory.memsw.failcnt # show the number of memory+Swap hits limits
>>> memory.max_usage_in_bytes # show max memory usage recorded
>>> @@ -72,6 +76,9 @@ Brief summary of control files.
>>> memory.oom_control # set/show oom controls.
>>> memory.numa_stat # show the number of memory usage per numa node
>>>
>>> + memory.independent_kmem_limit # select whether or not kernel memory limits are
>>> + independent of user limits
>>> +
>>> 1. History
>>>
>>> The memory controller has a long history. A request for comments for the memory
>>> @@ -255,6 +262,25 @@ When oom event notifier is registered, event will be delivered.
>>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>>> zone->lru_lock, it has no lock of its own.
>>>
>>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>>> +
>>> + With the Kernel memory extension, the Memory Controller is able to limit
>>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>>> +different than user memory, since it can't be swapped out, which makes it
>>> +possible to DoS the system by consuming too much of this precious resource.
>>> +Kernel memory limits are not imposed for the root cgroup.
>>> +
>>> +Memory limits as specified by the standard Memory Controller may or may not
>>> +take kernel memory into consideration. This is achieved through the file
>>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>>> +memory to be controlled separately.
>>> +
>>> +When kernel memory limits are not independent, the limit values set in
>>> +memory.kmem files are ignored.
>>> +
>>> +Currently no soft limit is implemented for kernel memory. It is future work
>>> +to trigger slab reclaim when those limits are reached.
>>> +
>
> Ying Han was also looking into this (cc'ing her)
>
>>> 3. User Interface
>>>
>>> 0. Configuration
>>> diff --git a/init/Kconfig b/init/Kconfig
>>> index d627783..49e5839 100644
>>> --- a/init/Kconfig
>>> +++ b/init/Kconfig
>>> @@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
>>> For those who want to have the feature enabled by default should
>>> select this option (if, for some reason, they need to disable it
>>> then swapaccount=0 does the trick).
>>> +config CGROUP_MEM_RES_CTLR_KMEM
>>> + bool "Memory Resource Controller Kernel Memory accounting"
>>> + depends on CGROUP_MEM_RES_CTLR
>>> + default y
>>> + help
>>> + The Kernel Memory extension for Memory Resource Controller can limit
>>> + the amount of memory used by kernel objects in the system. Those are
>>> + fundamentally different from the entities handled by the standard
>>> + Memory Controller, which are page-based, and can be swapped. Users of
>>> + the kmem extension can use it to guarantee that no group of processes
>>> + will ever exhaust kernel resources alone.
>>>
>>> config CGROUP_PERF
>>> bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>>> index ebd1e86..d32e931 100644
>>> --- a/mm/memcontrol.c
>>> +++ b/mm/memcontrol.c
>>> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
>>> #define do_swap_account (0)
>>> #endif
>>>
>>> -
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +int do_kmem_account __read_mostly = 1;
>>> +#else
>>> +#define do_kmem_account 0
>>> +#endif
>>> /*
>>> * Statistics for memory cgroup.
>>> */
>>> @@ -270,6 +274,10 @@ struct mem_cgroup {
>>> */
>>> struct res_counter memsw;
>>> /*
>>> + * the counter to account for kmem usage.
>>> + */
>>> + struct res_counter kmem;
>>> + /*
>>> * Per cgroup active and inactive list, similar to the
>>> * per zone LRU lists.
>>> */
>>> @@ -321,6 +329,11 @@ struct mem_cgroup {
>>> */
>>> unsigned long move_charge_at_immigrate;
>>> /*
>>> + * Should kernel memory limits be stabilished independently
>>> + * from user memory ?
>>> + */
>>> + int kmem_independent;
>>> + /*
>>> * percpu counter.
>>> */
>>> struct mem_cgroup_stat_cpu *stat;
>>> @@ -388,9 +401,14 @@ enum charge_type {
>>> };
>>>
>>> /* for encoding cft->private value on file */
>>> -#define _MEM (0)
>>> -#define _MEMSWAP (1)
>>> -#define _OOM_TYPE (2)
>>> +
>>> +enum mem_type {
>>> + _MEM = 0,
>>> + _MEMSWAP,
>>> + _OOM_TYPE,
>>> + _KMEM,
>>> +};
>>> +
>>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>>> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
>>> u64 val;
>>>
>>> if (!mem_cgroup_is_root(mem)) {
>>> + val = 0;
>>> + if (!mem->kmem_independent)
>>> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
>>> if (!swap)
>>> - return res_counter_read_u64(&mem->res, RES_USAGE);
>>> + val += res_counter_read_u64(&mem->res, RES_USAGE);
>>> else
>>> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
>>> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
>>> +
>>> + return val;
>>> }
>>>
>>> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
>>> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>>> else
>>> val = res_counter_read_u64(&mem->memsw, name);
>>> break;
>>> + case _KMEM:
>>> + val = res_counter_read_u64(&mem->kmem, name);
>>> + break;
>>> +
>>> default:
>>> BUG();
>>> break;
>>> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
>>> return 0;
>>> }
>>>
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
>>> +{
>>> + return mem_cgroup_from_cont(cont)->kmem_independent;
>>> +}
>>> +
>>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>>> + u64 val)
>>> +{
>>> + cgroup_lock();
>>> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
>>> + cgroup_unlock();
>>> + return 0;
>>> +}
>
> I know we have a lot of pending xxx_from_cont() and struct cgroup
> *cont, can we move it to memcg notation to be more consistent with our
> usage. There is a patch to convert old usage
>
>>> +#endif
>>>
>>> static struct cftype mem_cgroup_files[] = {
>>> {
>>> @@ -4877,6 +4919,47 @@ static int register_memsw_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>> }
>>> #endif
>>>
>>> +
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +static struct cftype kmem_cgroup_files[] = {
>>> + {
>>> + .name = "independent_kmem_limit",
>>> + .read_u64 = kmem_limit_independent_read,
>>> + .write_u64 = kmem_limit_independent_write,
>>> + },
>>> + {
>>> + .name = "kmem.usage_in_bytes",
>>> + .private = MEMFILE_PRIVATE(_KMEM, RES_USAGE),
>>> + .read_u64 = mem_cgroup_read,
>>> + },
>>> + {
>>> + .name = "kmem.limit_in_bytes",
>>> + .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT),
>>> + .read_u64 = mem_cgroup_read,
>>> + },
>>> +};
>>> +
>>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>> +{
>>> + struct mem_cgroup *mem = mem_cgroup_from_cont(cont);
>>> + int ret = 0;
>>> +
>>> + if (!do_kmem_account)
>>> + return 0;
>>> +
>>> + if (!mem_cgroup_is_root(mem))
>>> + ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
>>> + ARRAY_SIZE(kmem_cgroup_files));
>>> + return ret;
>>> +};
>>> +
>>> +#else
>>> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
>>> +{
>>> + return 0;
>>> +}
>>> +#endif
>>> +
>>> static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
>>> {
>>> struct mem_cgroup_per_node *pn;
>>> @@ -5075,6 +5158,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>>> if (parent&& parent->use_hierarchy) {
>>> res_counter_init(&mem->res,&parent->res);
>>> res_counter_init(&mem->memsw,&parent->memsw);
>>> + res_counter_init(&mem->kmem,&parent->kmem);
>>> /*
>>> * We increment refcnt of the parent to ensure that we can
>>> * safely access it on res_counter_charge/uncharge.
>>> @@ -5085,6 +5169,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
>>> } else {
>>> res_counter_init(&mem->res, NULL);
>>> res_counter_init(&mem->memsw, NULL);
>>> + res_counter_init(&mem->kmem, NULL);
>>> }
>>> mem->last_scanned_child = 0;
>>> mem->last_scanned_node = MAX_NUMNODES;
>>> @@ -5129,6 +5214,10 @@ static int mem_cgroup_populate(struct cgroup_subsys *ss,
>>>
>>> if (!ret)
>>> ret = register_memsw_files(cont, ss);
>>> +
>>> + if (!ret)
>>> + ret = register_kmem_files(cont, ss);
>>> +
>>> return ret;
>>> }
>>>
>>> @@ -5665,3 +5754,17 @@ static int __init enable_swap_account(char *s)
>>> __setup("swapaccount=", enable_swap_account);
>>>
>>> #endif
>>> +
>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>>> +static int __init disable_kmem_account(char *s)
>>> +{
>>> + /* consider enabled if no parameter or 1 is given */
>>> + if (!strcmp(s, "1"))
>>> + do_kmem_account = 1;
>>> + else if (!strcmp(s, "0"))
>>> + do_kmem_account = 0;
>>> + return 1;
>>> +}
>>> +__setup("kmemaccount=", disable_kmem_account);
>>> +
>>> +#endif
>
> The infrastructure looks OK, we need better integration with
> statistics for kmem usage.
>
> Balbir Singh
Hello Balbir,
Thank you for your comments.
I agree here. With this patch, however, I am only trying to lay down the
foundations needed for the rest of the patches, that touch tcp memory
pressure conditions.
--
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: TCP_DELACK_MIN vs TCP_ATO_MIN
From: rohan puri @ 2011-09-22 4:01 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev, kernelnewbies
In-Reply-To: <CAEnQRZBdoPBn1bidga5c89n-Oru2JzrQa9bTj_tBG4HxS33PyA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 439 bytes --]
On Wed, Sep 21, 2011 at 8:58 PM, Daniel Baluta <daniel.baluta@gmail.com>wrote:
> > Now the default value is of both the macros is same.
> >
> > But if you want to make delayed ack timeout configurable, then I think
> you
> > should give proc interface for TCP_DELACK_MIN.
>
> Thanks Rohan. Then also I have to export TCP_DELACK_MAX since I think
> ato cannot grow over this value.
>
> thanks,
> Daniel.
>
Yes Daniel.
Regards,
Rohan Puri
[-- Attachment #1.2: Type: text/html, Size: 778 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Michael Kerrisk @ 2011-09-22 4:15 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Neil Horman, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110920143109.GB16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
Ben, Neil,
On Tue, Sep 20, 2011 at 4:31 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> On Tue, Sep 20, 2011 at 10:12:34AM -0400, Benjamin Poirier wrote:
>> On 11-09-20 09:38, Neil Horman wrote:
>> > On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
>> > > On 11-09-20 08:14, Michael Kerrisk wrote:
>> > > > Hello Benjamin, Neil,
>> > > >
>> [snip]
>> > > >
>> > > > Could you describe the required change in terms of how the man page
>> > > > text should look--i.e., rewrite the passage as you think it should
>> > > > look?
>> > >
>> > > How about changing it to:
>> > > IP_MTU_DISCOVER (since Linux 2.2)
>> > > Set or receive the Path MTU Discovery setting for a socket. When
>> > > enabled, the don't-fragment flag is set on all outgoing packets.
>> > > Linux will perform Path MTU Discovery as defined in RFC 1191 on
>> > > SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
>> > > user's responsibility to packetize the data in MTU sized chunks
>> > > and to do the retransmits if necessary. The kernel will reject
>> > > (with EMSGSIZE) datagrams that are bigger than the known path
>> > > MTU. The system-wide default is controlled by the
>> > > /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>> > >
>> > > Path MTU discovery flags Meaning
>> > > [...]
>> > >
>> > > There are some differences between _DO and _WANT that are glossed over
>> > > in this description, but I suppose there's only so much detail you can
>> > > put in...
>> > >
>> > > Thanks,
>> > > -Ben
>> > >
>> > Yeah, I think thats close, but its only the users responsibility to package
>> > datagrams in mtu sized chunks if they force the dont fragment bit on. If they
>> > go wtih the default, the stack will fragment a datagram is it sees fit according
>> > to the mtu of the path it traverses
>>
>> Exactly. To get into this level of detail, I think we have to mention
>> the option value, not just enabled/disabled. Let's try like this:
>>
>> IP_MTU_DISCOVER (since Linux 2.2)
>> Set or receive the Path MTU Discovery setting for a socket. When
>> enabled, Linux will perform Path MTU Discovery as defined in RFC
>> 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets,
>> IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
>> outgoing packets. It is the user's responsibility to packetize
>> the data in MTU sized chunks and to do the retransmits if
>> necessary. The kernel will reject (with EMSGSIZE) datagrams
>> that are bigger than the known path MTU. IP_PMTUDISC_WANT will
>> fragment a datagram if needed according to the path MTU or will
>> set the don't-fragment flag otherwise.
>>
>> The system-wide default can be toggled between IP_PMTUDISC_WANT
>> and IP_PMTUDISC_DONT by writting to the
>> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>>
> Yes, that sounds good to me. Thanks for doing this!
> Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
applied that change for man-pages-3.34.
Ben, I added one small piece ti the description of
/proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
the entire text below. Perhaps you could take a quick scan, to make
sure that the changed text is consistent with the whole piece.
Thanks,
Michael
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a
socket. When enabled, Linux will perform Path MTU Dis-
covery as defined in RFC 1191 on SOCK_STREAM sockets.
For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the
don't-fragment flag to be set on all outgoing packets.
The don't-fragment flag is set on all outgoing data-
grams. It is the user's responsibility to packetize the
data in MTU-sized chunks and to do the retransmits if
necessary. The kernel will reject (with EMSGSIZE) data-
grams that are bigger than the known path MTU.
IP_PMTUDISC_WANT will fragment a datagram if needed
according to the path MTU, or will set the don't-frag-
ment flag otherwise.
The system-wide default can be toggled between IP_PMTUD-
ISC_WANT and IP_PMTUDISC_DONT by writing (respectively,
zero and nonzero values) to the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.
Path MTU discovery flags Meaning
IP_PMTUDISC_WANT Use per-route settings.
IP_PMTUDISC_DONT Never do Path MTU Discovery.
IP_PMTUDISC_DO Always do Path MTU Discovery.
IP_PMTUDISC_PROBE Set DF but ignore Path MTU.
When PMTU discovery is enabled, the kernel automatically
keeps track of the path MTU per destination host. When
it is connected to a specific peer with connect(2), the
currently known path MTU can be retrieved conveniently
using the IP_MTU socket option (e.g., after an EMSGSIZE
error occurred). The path MTU may change over time.
For connectionless sockets with many destinations, the
new MTU for a given destination can also be accessed
using the error queue (see IP_RECVERR). A new error
will be queued for every incoming MTU update.
While MTU discovery is in progress, initial packets from
datagram sockets may be dropped. Applications using UDP
should be aware of this and not take it into account for
their packet retransmit strategy.
To bootstrap the path MTU discovery process on uncon-
nected sockets, it is possible to start with a big data-
gram size (up to 64K-headers bytes long) and let it
shrink by updates of the path MTU.
To get an initial estimate of the path MTU, connect a
datagram socket to the destination address using con-
nect(2) and retrieve the MTU by calling getsockopt(2)
with the IP_MTU option.
It is possible to implement RFC 4821 MTU probing with
SOCK_DGRAM or SOCK_RAW sockets by setting a value of
IP_PMTUDISC_PROBE (available since Linux 2.6.22). This
is also particularly useful for diagnostic tools such as
tracepath(8) that wish to deliberately send probe pack-
ets larger than the observed Path MTU.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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
* [PATCH v4 2/3] net/fec: fix fec1 check in fec_enet_mii_init()
From: Shawn Guo @ 2011-09-22 5:10 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316668218-10194-1-git-send-email-shawn.guo@linaro.org>
In function fec_enet_mii_init(), it uses non-zero pdev->id as part
of the condition to check the second fec instance (fec1). This works
before the driver supports device tree probe. But in case of device
tree probe, pdev->id is -1 which is also non-zero, so the logic becomes
broken when device tree probe gets supported.
The patch change the logic to check "pdev->id > 0" as the part of the
condition for identifying fec1.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
---
drivers/net/ethernet/freescale/fec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 9c1d059..2bbe6a5 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -996,7 +996,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* mdio interface in board design, and need to be configured by
* fec0 mii_bus.
*/
- if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id) {
+ if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id > 0) {
/* fec1 uses fec0 mii_bus */
fep->mii_bus = fec0_mii_bus;
return 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCH v4 0/3] add fec support for imx6q
From: Shawn Guo @ 2011-09-22 5:10 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches
This series adds imx6q enet support. The imx6q enet is a derivative of
imx28 enet controller. It fixed the frame endian issue found on imx28,
and added 1 Gbps support.
Changes since v3:
* The minus one on phy_speed should happend before left shift.
Changes since v2:
* Refine patch #1 to get fec_reset_phy() return void
Changes since v1:
* Fix typo pointed out by Francois Romieu
* Drop patch #3 in the v1
* Rebase on net-next tree
Thanks.
Shawn Guo (3):
net/fec: fec_reset_phy() does not need to always succeed
net/fec: fix fec1 check in fec_enet_mii_init()
net/fec: add imx6q enet support
drivers/net/ethernet/freescale/Kconfig | 9 ++--
drivers/net/ethernet/freescale/fec.c | 79 +++++++++++++++++++++++---------
2 files changed, 61 insertions(+), 27 deletions(-)
^ permalink raw reply
* [PATCH v4 1/3] net/fec: fec_reset_phy() does not need to always succeed
From: Shawn Guo @ 2011-09-22 5:10 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316668218-10194-1-git-send-email-shawn.guo@linaro.org>
FEC can work without a phy reset on some platforms, which means not
very platform necessarily have a phy-reset gpio encoded in device tree.
Even on the platforms that have the gpio, FEC can work without
resetting phy for some cases, e.g. boot loader has done that.
So it makes more sense to have the phy-reset-gpio request failure as
a debug message rather than a warning, and get fec_reset_phy() return
void since the caller does not check the return anyway.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
---
drivers/net/ethernet/freescale/fec.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 158b82e..9c1d059 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -1411,24 +1411,22 @@ static int __devinit fec_get_phy_mode_dt(struct platform_device *pdev)
return -ENODEV;
}
-static int __devinit fec_reset_phy(struct platform_device *pdev)
+static void __devinit fec_reset_phy(struct platform_device *pdev)
{
int err, phy_reset;
struct device_node *np = pdev->dev.of_node;
if (!np)
- return -ENODEV;
+ return;
phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
if (err) {
- pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
- return err;
+ pr_debug("FEC: failed to get gpio phy-reset: %d\n", err);
+ return;
}
msleep(1);
gpio_set_value(phy_reset, 1);
-
- return 0;
}
#else /* CONFIG_OF */
static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
@@ -1436,13 +1434,12 @@ static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
return -ENODEV;
}
-static inline int fec_reset_phy(struct platform_device *pdev)
+static inline void fec_reset_phy(struct platform_device *pdev)
{
/*
* In case of platform probe, the reset has been done
* by machine code.
*/
- return 0;
}
#endif /* CONFIG_OF */
--
1.7.4.1
^ permalink raw reply related
* [PATCH v4 3/3] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-22 5:10 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316668218-10194-1-git-send-email-shawn.guo@linaro.org>
The imx6q enet is a derivative of imx28 enet controller. It fixed
the frame endian issue found on imx28, and added 1 Gbps support.
It also fixes a typo on vendor name in Kconfig.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/Kconfig | 9 ++--
drivers/net/ethernet/freescale/fec.c | 64 +++++++++++++++++++++++++------
2 files changed, 55 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 4dbe41f..1cf6716 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
default y
depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC || \
+ ARCH_MXC || ARCH_MXS || \
(PPC_MPC52xx && PPC_BESTCOMM)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
@@ -16,16 +16,15 @@ config NET_VENDOR_FREESCALE
Note that the answer to this question doesn't directly affect the
kernel: saying N will just cause the configurator to skip all
- the questions about IBM devices. If you say Y, you will be asked for
- your specific card in the following questions.
+ the questions about Freescale devices. If you say Y, you will be
+ asked for your specific card in the following questions.
if NET_VENDOR_FREESCALE
config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC)
- default IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC if ARM
+ ARCH_MXC || ARCH_MXS)
select PHYLIB
---help---
Say Y here if you want to use the built-in 10/100 Fast ethernet
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 2bbe6a5..6a6a83d 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -18,7 +18,7 @@
* Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
* Copyright (c) 2004-2006 Macq Electronique SA.
*
- * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
*/
#include <linux/module.h>
@@ -72,6 +72,10 @@
#define FEC_QUIRK_SWAP_FRAME (1 << 1)
/* Controller uses gasket */
#define FEC_QUIRK_USE_GASKET (1 << 2)
+/* Controller has GBIT support */
+#define FEC_QUIRK_HAS_GBIT (1 << 3)
+/* Controller's phy_speed bit field need to minus one */
+#define FEC_QUIRK_PHY_SPEED_MINUS_ONE (1 << 4)
static struct platform_device_id fec_devtype[] = {
{
@@ -88,6 +92,10 @@ static struct platform_device_id fec_devtype[] = {
.name = "imx28-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
}, {
+ .name = "imx6q-fec",
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_PHY_SPEED_MINUS_ONE,
+ }, {
/* sentinel */
}
};
@@ -97,12 +105,14 @@ enum imx_fec_type {
IMX25_FEC = 1, /* runs on i.mx25/50/53 */
IMX27_FEC, /* runs on i.mx27/35/51 */
IMX28_FEC,
+ IMX6Q_FEC,
};
static const struct of_device_id fec_dt_ids[] = {
{ .compatible = "fsl,imx25-fec", .data = &fec_devtype[IMX25_FEC], },
{ .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
{ .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
+ { .compatible = "fsl,imx6q-fec", .data = &fec_devtype[IMX6Q_FEC], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fec_dt_ids);
@@ -373,6 +383,7 @@ fec_restart(struct net_device *ndev, int duplex)
int i;
u32 temp_mac[2];
u32 rcntl = OPT_FRAME_SIZE | 0x04;
+ u32 ecntl = 0x2; /* ETHEREN */
/* Whack a reset. We should wait for this. */
writel(1, fep->hwp + FEC_ECNTRL);
@@ -442,18 +453,23 @@ fec_restart(struct net_device *ndev, int duplex)
/* Enable flow control and length check */
rcntl |= 0x40000000 | 0x00000020;
- /* MII or RMII */
- if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
+ /* RGMII, RMII or MII */
+ if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ rcntl |= (1 << 6);
+ else if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
rcntl |= (1 << 8);
else
rcntl &= ~(1 << 8);
- /* 10M or 100M */
- if (fep->phy_dev && fep->phy_dev->speed == SPEED_100)
- rcntl &= ~(1 << 9);
- else
- rcntl |= (1 << 9);
-
+ /* 1G, 100M or 10M */
+ if (fep->phy_dev) {
+ if (fep->phy_dev->speed == SPEED_1000)
+ ecntl |= (1 << 5);
+ else if (fep->phy_dev->speed == SPEED_100)
+ rcntl &= ~(1 << 9);
+ else
+ rcntl |= (1 << 9);
+ }
} else {
#ifdef FEC_MIIGSK_ENR
if (id_entry->driver_data & FEC_QUIRK_USE_GASKET) {
@@ -478,8 +494,15 @@ fec_restart(struct net_device *ndev, int duplex)
}
writel(rcntl, fep->hwp + FEC_R_CNTRL);
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ /* enable ENET endian swap */
+ ecntl |= (1 << 8);
+ /* enable ENET store and forward mode */
+ writel(1 << 8, fep->hwp + FEC_X_WMRK);
+ }
+
/* And last, enable the transmit and receive processing */
- writel(2, fep->hwp + FEC_ECNTRL);
+ writel(ecntl, fep->hwp + FEC_ECNTRL);
writel(0, fep->hwp + FEC_R_DES_ACTIVE);
/* Enable interrupts we wish to service */
@@ -490,6 +513,8 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
/* We cannot expect a graceful transmit stop without link !!! */
if (fep->link) {
@@ -504,6 +529,10 @@ fec_stop(struct net_device *ndev)
udelay(10);
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+
+ /* We have to keep ENET enabled to have MII interrupt stay working */
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ writel(2, fep->hwp + FEC_ECNTRL);
}
@@ -918,6 +947,8 @@ static int fec_enet_mdio_reset(struct mii_bus *bus)
static int fec_enet_mii_probe(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
struct phy_device *phy_dev = NULL;
char mdio_bus_id[MII_BUS_ID_SIZE];
char phy_name[MII_BUS_ID_SIZE + 3];
@@ -949,14 +980,18 @@ static int fec_enet_mii_probe(struct net_device *ndev)
snprintf(phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);
phy_dev = phy_connect(ndev, phy_name, &fec_enet_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ fep->phy_interface);
if (IS_ERR(phy_dev)) {
printk(KERN_ERR "%s: could not attach to PHY\n", ndev->name);
return PTR_ERR(phy_dev);
}
/* mask with MAC supported features */
- phy_dev->supported &= PHY_BASIC_FEATURES;
+ if (id_entry->driver_data & FEC_QUIRK_HAS_GBIT)
+ phy_dev->supported &= PHY_GBIT_FEATURES;
+ else
+ phy_dev->supported &= PHY_BASIC_FEATURES;
+
phy_dev->advertising = phy_dev->supported;
fep->phy_dev = phy_dev;
@@ -1007,7 +1042,10 @@ static int fec_enet_mii_init(struct platform_device *pdev)
/*
* Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
*/
- fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
+ fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
+ if (id_entry->driver_data & FEC_QUIRK_PHY_SPEED_MINUS_ONE)
+ fep->phy_speed--;
+ fep->phy_speed <<= 1;
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
fep->mii_bus = mdiobus_alloc();
--
1.7.4.1
^ permalink raw reply related
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2011-09-22 5:16 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Kasper Pedersen, Matt Carlson
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/ethernet/broadcom/tg3.c between commit 5c1e688388f6 ("tg3:
fix VLAN tagging regression") from Linus' tree and commit 93a700a9d20b
("tg3: Code movement") from the net tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/broadcom/tg3.c
index 4a1374d,1485013..0000000
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@@ -6234,15 -6734,17 +6734,15 @@@ static netdev_tx_t tg3_start_xmit(struc
}
}
+ if (tg3_flag(tp, USE_JUMBO_BDFLAG) &&
+ !mss && skb->len > VLAN_ETH_FRAME_LEN)
+ base_flags |= TXD_FLAG_JMB_PKT;
+
-#ifdef BCM_KERNEL_SUPPORTS_8021Q
if (vlan_tx_tag_present(skb)) {
base_flags |= TXD_FLAG_VLAN;
vlan = vlan_tx_tag_get(skb);
}
-#endif
- if (tg3_flag(tp, USE_JUMBO_BDFLAG) &&
- !mss && skb->len > VLAN_ETH_FRAME_LEN)
- base_flags |= TXD_FLAG_JMB_PKT;
-
len = skb_headlen(skb);
mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Greg Thelen @ 2011-09-22 5:58 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
netdev, linux-mm, kirill
In-Reply-To: <1316393805-3005-2-git-send-email-glommer@parallels.com>
On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa <glommer@parallels.com> wrote:
> @@ -270,6 +274,10 @@ struct mem_cgroup {
> */
> struct res_counter memsw;
> /*
> + * the counter to account for kmem usage.
> + */
> + struct res_counter kmem;
> + /*
I don't see this charged, is this used in a later patch in this series?
> @@ -5665,3 +5754,17 @@ static int __init enable_swap_account(char *s)
> __setup("swapaccount=", enable_swap_account);
>
> #endif
> +
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
> +static int __init disable_kmem_account(char *s)
Minor nit. To be consistent with the other memcg __setup options, I
think this should be renamed to enable_kmem_account().
> +{
> + /* consider enabled if no parameter or 1 is given */
> + if (!strcmp(s, "1"))
> + do_kmem_account = 1;
> + else if (!strcmp(s, "0"))
> + do_kmem_account = 0;
> + return 1;
> +}
> +__setup("kmemaccount=", disable_kmem_account);
> +
> +#endif
^ 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