* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 9:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA8ECF75.33BFF%roprabhu@cisco.com>
On Thu, Sep 08, 2011 at 08:00:53PM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/8/11 12:33 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Sep 08, 2011 at 12:23:56PM -0700, Roopa Prabhu wrote:
> >>>
> >>> I think the main usecase for passthru mode is to assign a SR-IOV VF to
> >>> a single guest.
> >>>
> >> Yes and for the passthru usecase this patch should be enough to enable
> >> filtering in hw (eventually like I indicated before I need to fix vlan
> >> filtering too).
> >
> > So with filtering in hw, and in sriov VF case, VFs
> > actually share a filtering table. How will that
> > be partitioned?
>
> AFAIK, though it might maintain a single filter table space in hw, hw does
> know which filter belongs to which VF. And the OS driver does not need to do
> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
> registered with a VF netdev are registered with the hw by the driver. And hw
> will filter and send only pkts that the VF has expressed interest in.
>
> No special filter partitioning in hw is required.
>
> Thanks,
> Roopa
Yes, but what I mean is, if the size of the single filter table
is limited, we need to decide how many addresses is
each guest allowed. If we let one guest ask for
as many as it wants, it can lock others out.
--
MST
^ permalink raw reply
* Re: [PATCH] macmace: disable only the dma interrupt
From: Finn Thain @ 2011-09-11 10:02 UTC (permalink / raw)
To: David Miller; +Cc: linux-m68k, netdev
In-Reply-To: <20110910.143046.520109083086760748.davem@davemloft.net>
On Sat, 10 Sep 2011, David Miller wrote:
> From: Finn Thain <fthain@telegraphics.com.au>
> Date: Sun, 11 Sep 2011 01:02:16 +1000 (EST)
>
> > Don't disable all interrupts, just disable the relevant one.
> >
> > Also move a couple of printk calls outside of local_irq_save/restore.
> >
> > Tested on a Quadra 660av.
> >
> > Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>
> Using disable_irq() is very expensive, and when done from an interrupt
> handler can deadlock especially on SMP (which I understand might not be
> relevant here).
>
> I really can't see why you'd do things this way, especially since
> interrupt handlers under Linux now unconditionally always run with cpu
> interrupts disabled.
I wasn't aware of this (I was under the impression that a higher priority
interrupt could be serviced). Please disregard this patch.
Finn
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-11 13:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <20110911094449.GF27096@redhat.com>
On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>> AFAIK, though it might maintain a single filter table space in hw, hw does
>> know which filter belongs to which VF. And the OS driver does not need to do
>> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
>> registered with a VF netdev are registered with the hw by the driver. And hw
>> will filter and send only pkts that the VF has expressed interest in.
>>
>> No special filter partitioning in hw is required.
>>
>> Thanks,
>> Roopa
>
> Yes, but what I mean is, if the size of the single filter table
> is limited, we need to decide how many addresses is
> each guest allowed. If we let one guest ask for
> as many as it wants, it can lock others out.
Yes true. In these cases ie when the number of unicast addresses being
registered is more than it can handle, The VF driver will put the VF in
promiscuous mode (Or at least its supposed to do. I think all drivers do
that).
Thanks,
Roopa
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-11 13:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <20110911093832.GD27096@redhat.com>
On 9/11/11 2:38 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
>>
>>
>>
>> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>>> On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
>>>>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
>>>>>> - In macvlan passthru mode the single guest virtio-nic connected will
>>>>>> receive traffic that he requested for
>>>>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
>>>>>> physical nic will see all other guest traffic
>>>>>> but the filtering at guest virtio-nic
>>>>>
>>>>> I don't think guests currently filter anything.
>>>>>
>>>> I was referring to Qemu-kvm virtio-net in
>>>> virtion_net_receive->receive_filter. I think It only passes pkts that the
>>>> guest OS is interested. It uses the filter table that I am passing to
>>>> macvtap in this patch.
>>>
>>> This happens after userspace thread gets woken up and data
>>> is copied there. So relying on filtering at that level is
>>> going to be very inefficient on a system with
>>> multiple active guests. Further, and for that reason, vhost-net
>>> doesn't do filtering at all, relying on the backends
>>> to pass it correct packets.
>>
>> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
>> and for non-PASSTHRU when there is a single guest connected to a VF.
>> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
>> better than putting the VF in promiscuous mode.
>> But to address the concern you mention above, in phase 2 when we have more
>> than one guest sharing the VF,
>
> It's probably more interesting for a card without SRIOV support.
>
If its an SRIOV card I am assuming people likely using PASSTHRU mode.
Non-SRIOV cards will use any of the non-PASSTHRU mode.
>> we will have to add filter lookup in macvlan
>> to filter pkts for each guest.
>
> Any chance to enable hardware filters for that?
>
NAFAIK. Am not sure how you would do it too. Its still a single device from
where the host receives traffic from.
Thanks,
Roopa
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 18:52 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <CA92031A.33DE1%roprabhu@cisco.com>
On Sun, Sep 11, 2011 at 06:18:02AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/11/11 2:38 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Fri, Sep 09, 2011 at 09:33:33AM -0700, Roopa Prabhu wrote:
> >>
> >>
> >>
> >> On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >>> On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
> >>>>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
> >>>>>> - In macvlan passthru mode the single guest virtio-nic connected will
> >>>>>> receive traffic that he requested for
> >>>>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
> >>>>>> physical nic will see all other guest traffic
> >>>>>> but the filtering at guest virtio-nic
> >>>>>
> >>>>> I don't think guests currently filter anything.
> >>>>>
> >>>> I was referring to Qemu-kvm virtio-net in
> >>>> virtion_net_receive->receive_filter. I think It only passes pkts that the
> >>>> guest OS is interested. It uses the filter table that I am passing to
> >>>> macvtap in this patch.
> >>>
> >>> This happens after userspace thread gets woken up and data
> >>> is copied there. So relying on filtering at that level is
> >>> going to be very inefficient on a system with
> >>> multiple active guests. Further, and for that reason, vhost-net
> >>> doesn't do filtering at all, relying on the backends
> >>> to pass it correct packets.
> >>
> >> Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
> >> and for non-PASSTHRU when there is a single guest connected to a VF.
> >> For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
> >> better than putting the VF in promiscuous mode.
> >> But to address the concern you mention above, in phase 2 when we have more
> >> than one guest sharing the VF,
> >
> > It's probably more interesting for a card without SRIOV support.
> >
> If its an SRIOV card I am assuming people likely using PASSTHRU mode.
> Non-SRIOV cards will use any of the non-PASSTHRU mode.
>
>
> >> we will have to add filter lookup in macvlan
> >> to filter pkts for each guest.
> >
> > Any chance to enable hardware filters for that?
> >
> NAFAIK. Am not sure how you would do it too. Its still a single device from
> where the host receives traffic from.
>
> Thanks,
> Roopa
VMDQ cards might let you program mac addresses for individula rings.
--
MST
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Michael S. Tsirkin @ 2011-09-11 19:03 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA920319.33DE1%roprabhu@cisco.com>
On Sun, Sep 11, 2011 at 06:18:01AM -0700, Roopa Prabhu wrote:
>
>
>
> On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> >>
> >> AFAIK, though it might maintain a single filter table space in hw, hw does
> >> know which filter belongs to which VF. And the OS driver does not need to do
> >> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
> >> registered with a VF netdev are registered with the hw by the driver. And hw
> >> will filter and send only pkts that the VF has expressed interest in.
> >>
> >> No special filter partitioning in hw is required.
> >>
> >> Thanks,
> >> Roopa
> >
> > Yes, but what I mean is, if the size of the single filter table
> > is limited, we need to decide how many addresses is
> > each guest allowed. If we let one guest ask for
> > as many as it wants, it can lock others out.
>
> Yes true. In these cases ie when the number of unicast addresses being
> registered is more than it can handle, The VF driver will put the VF in
> promiscuous mode (Or at least its supposed to do. I think all drivers do
> that).
>
>
> Thanks,
> Roopa
Right, so that works at least but likely performs worse
than a hardware filter. So we better allocate it in
some fair way, as a minimum. Maybe a way for
the admin to control that allocation is useful.
--
MST
^ permalink raw reply
* Re: r8169 hard-freezes the system on big network loads
From: Michael Brade @ 2011-09-11 20:16 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, nic_swsd
In-Reply-To: <20110823131726.GA21092@electric-eye.fr.zoreil.com>
On Tuesday 23 August 2011 15:17:26 Francois Romieu wrote:
> Francois Romieu <romieu@fr.zoreil.com> :
> [...]
>
> > Yes. There is enough data for me to reproduce the bug with the
> > exact same chipset.
>
> I can not generate a single rx error and the driver refuses to crash :o/
>
> Can you apply the patch below on top of 3.1.0-rc3 and see if it makes
> a difference ?
Sorry for the delay, I have had only two days for email in the last few weeks
and additionally kernel.org was and still is down.
Does it have to be 3.1.0-rc3 or is 3.0.1 ok as well? If so, I have another bad
news: 3.0.1 still crashes with this patch. It took me a lot longer to crash it
but eventually it did happen. Not sure why it took longer, I guess I didn't
generate enough throughput.
If you want me to use 3.1.0 then we'll have to wait until git.kernel.org is
back...
thanks,
Michael
> Thanks.
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 02339b3..c54ed17 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -5326,10 +5326,6 @@ static int rtl8169_rx_interrupt(struct net_device
> *dev, dev->stats.rx_length_errors++;
> if (status & RxCRC)
> dev->stats.rx_crc_errors++;
> - if (status & RxFOVF) {
> - rtl8169_schedule_work(dev, rtl8169_reset_task);
> - dev->stats.rx_fifo_errors++;
> - }
> rtl8169_mark_to_asic(desc, rx_buf_sz);
> } else {
> struct sk_buff *skb;
^ permalink raw reply
* [PATCH resend] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: Wanlong Gao @ 2011-09-12 1:36 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem, Gao feng, Gao feng, Eric Dumazet
In-Reply-To: <1315675150-3012-1-git-send-email-wanlong.gao@gmail.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
add new fib rule can cause BUG_ON happen
the reproduce shell is
ip rule add pref 38
ip rule add pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule del pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule add pref 38
then the BUG_ON will happen
del BUG_ON and use (ctarget == NULL) identify whether this rule is unresolved
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/fib_rules.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7ab0c0..3231b46 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -384,8 +384,8 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
- r->target == rule->pref) {
- BUG_ON(rtnl_dereference(r->ctarget) != NULL);
+ r->target == rule->pref &&
+ rtnl_dereference(r->ctarget) == NULL) {
rcu_assign_pointer(r->ctarget, rule);
if (--ops->unresolved_rules == 0)
break;
--
1.7.6
^ permalink raw reply related
* Re: Memory leak in ip_dst_cache
From: Kumar S @ 2011-09-12 3:38 UTC (permalink / raw)
To: Neil Horman; +Cc: Eric Dumazet, netdev
In-Reply-To: <20110910130416.GA2005@neilslaptop.think-freely.org>
Thanks Neil. I did try with prink(). I do see entries getting aged out, but they are not getting deallocated. This seems to be happening because of "ref_cnt". When the route entries are added the ref_cnt is set to 1. Looks this is causing trouble clearing the entries completely. If I set the ref_cnt to 0, I can see it working. Now I'm trying to understand whether this is right. Please let me know if you have any thoughts on it.
----- Original Message -----
From: Neil Horman <nhorman@tuxdriver.com>
To: Kumar S <ps2kumar@yahoo.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>; netdev <netdev@vger.kernel.org>
Sent: Saturday, September 10, 2011 6:04 AM
Subject: Re: Memory leak in ip_dst_cache
On Fri, Sep 09, 2011 at 03:53:45PM -0700, Kumar S wrote:
> Yes Eric, this command doesn't work on 2.6.24. Which timer are you suspecting?
>
He means that the timer that starts the the workqueue which calls dst_gc_task is
either delayed indefinately, or otherwise not run, which means that the route
cache will never be scanned for old entries. The implication being that, while
the dst entries aren't leaked per-se, but never expired, so they just sit
around. You can check this by instrumenting gc_dst_task with a printk or two
and watch to see if it ever pops up.
If you only have 512Mb of ram and want to really restrict you're cache size, you
should definately consider backporting the route cache rebuild patch to disable
the route cache usage entirely. It shouldn't be too hard to do.
Neil
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Sridhar Samudrala @ 2011-09-12 4:30 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Michael S. Tsirkin, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA920319.33DE1%roprabhu@cisco.com>
On 9/11/2011 6:18 AM, Roopa Prabhu wrote:
>
>
> On 9/11/11 2:44 AM, "Michael S. Tsirkin"<mst@redhat.com> wrote:
>
>>> AFAIK, though it might maintain a single filter table space in hw, hw does
>>> know which filter belongs to which VF. And the OS driver does not need to do
>>> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
>>> registered with a VF netdev are registered with the hw by the driver. And hw
>>> will filter and send only pkts that the VF has expressed interest in.
>>>
>>> No special filter partitioning in hw is required.
>>>
>>> Thanks,
>>> Roopa
>> Yes, but what I mean is, if the size of the single filter table
>> is limited, we need to decide how many addresses is
>> each guest allowed. If we let one guest ask for
>> as many as it wants, it can lock others out.
> Yes true. In these cases ie when the number of unicast addresses being
> registered is more than it can handle, The VF driver will put the VF in
> promiscuous mode (Or at least its supposed to do. I think all drivers do
> that).
>
What does putting VF in promiscuous mode mean? How can the NIC decide
which set
of mac addresses are passed to the VF? Does it mean VF sees all the
packets received
by the NIC including packets destined for other VFs/PF?
Thanks
Sridhar
^ permalink raw reply
* Re: [PATCH] per-cgroup tcp buffer limitation
From: Paul Menage @ 2011-09-12 5:03 UTC (permalink / raw)
To: Glauber Costa
Cc: Greg Thelen, linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Hiroyouki Kamezawa, Eric W. Biederman,
Suleiman Souhlal
In-Reply-To: <4E699341.9010606@parallels.com>
On Thu, Sep 8, 2011 at 9:17 PM, Glauber Costa <glommer@parallels.com> wrote:
> On 09/08/2011 06:53 PM, Greg Thelen wrote:
>>
>> On Wed, Sep 7, 2011 at 9:44 PM, Glauber Costa<glommer@parallels.com>
>> wrote:
>>
>> Thanks for your ideas and patience.
>
> Likewise. It is turning out to be a very fruitful
> discussion.
>
This also got a fair bit of attention at LPC on Thursday - shame you
couldn't make it, but I hope you had no problems getting your visa!
I definitely think that there was no consensus reached on unified
versus split charging - but I think that we can work around that and
keep everyone happy, see below.
>
> Risking being a bit polemic here, I think that when we do
> containers, we have to view the kernel a little bit like a shared resource
> that is not accounted to anybody. It is easy to account things like tcp
> buffer, but who do you account page tables for shared pages to? Or pinned
> dentries for shared filesystems ?
I'd say that if filesystems (or page tables) are shared between
containers / cgroups, then it's fair to do first-touch accounting. But
if a filesystem is shared between multiple processes in just one
container / cgroup then it should definitely be charged to that cgroup
(which you get automatically with first-touch accounting).
It might be reasonable to also allow the sysadmin to request a more
expensive form of accounting (probably either charge-all or
equal-share), if the code to support that didn't interfere with the
performance of the normal first-touch charging mechanism, or
complicate the code too much.
On the subject of filesystems specifically, see Greg Thelen's proposal
for using bind mounts to account on a bind mount to a given cgroup -
that could apply to dentries, page tables and other kernel memory as
well as page cache.
> Good that it scares you, it should. OTOH, userspace being
> able to set parameters to it, has nothing scary at all. A daemon in
> userspace can detect that you need more kernel space memory , and
> then - according to a policy you abide to - write to a file allowing
> it more, or maybe not - according to that same policy. It is very
> far away from "userspace driven reclaim".
It can do that, but it's a bit messy when all userspace really wants
to do is say "limit the total to X GB".
> No, I don't necessarily feel that need. I just thought it was
> cleaner to have entities with different purposes in different
> cgroups. If moving it to the memory controller would help you in any
> way, I can just do it. 80 % of this work is independent of where a
> cgroup file lives.
My feeling is also that it's more appropriate for this to live in
memcg. While the ability to mount subsystems separately gives nice
flexibility, in the case of userspace versus kernel memory, I'm having
trouble envisaging a realistic situation where you'd want them mounted
on different hierarchies.
> - kernel_memory_hard_limit.
> - kernel_memory_soft_limit.
>
> tcp memory would be the one defined in /proc, except if it is
> greater than any of the limits. Instead of testing for memory
> allocation against kmem.tcp_allocated_memory, we'd test it against
> memcg.kmem_pinned_memory.
>
This is definitely an improvement, but I'd say it's not enough. I
think we should consider something like:
- a root cgroup file (memory.unified?) that controls whether memory
limits are unified or split.
- this file can only be modified when there are no memory cgroups
created (other than the root, which we shouldn't be charging, I think)
- the 'active' control determines whether (all) child cgroups will
have memory.{limit,usage}_in_bytes files, or
memory.{kernel,user}_{limit,usage}_in_bytes files
- kernel memory will be charged either against 'kernel' or 'total'
depending on the value of unified
- userspace memory will be charged either against 'user' or 'total'
That way the kernel doesn't force a unified or split decision on
anyone, with I think zero performance hit and not much extra code.
You could even take this a step further. The following is probably
straying into the realm of overly-flexible, but I'll throw it into the
discussion anyway:
- define counters for various types of memory (e.g. total, user,
kernel, network, tcp, pagetables, dentries, etc)
- document what kind of memory is potentially charged against each
counter. (e.g. TCP buffers would be potentially charged against 'tcp',
'network', 'kernel' and 'total')
- have a memory.counters root cgroup file that allows the user to
specify which of the available counters are active. (only writeable
when no child cgroups, to avoid inconsistencies caused by changes
while memory is charged)
- default memory.counters to 'total'
- when memory.counters is updated, the memcg code builds the set of
targets for each chargeable entity. (e.g. if you enabled 'network' and
'total', then we'd update the charge_tcp array to contain something
like { &network_counter, &total_counter, NULL })
- charging for an object (TCP allocation, pagecache page, pagetable,
dentry, etc) just involves (trying to) charge all the counters set up
in that object's array. Since these arrays will be immutable once
child cgroups are being charged, they should be fairly well predicted.
This would give complete flexibility to userspace on the policy for
charging and reporting without incurring performance overhead for
systems that didn't care about some particular counter. (And without
complicating the code too much, I think).
Paul
--
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: Memory leak in ip_dst_cache
From: Eric Dumazet @ 2011-09-12 5:40 UTC (permalink / raw)
To: Kumar S; +Cc: Neil Horman, netdev
In-Reply-To: <1315798710.96027.YahooMailNeo@web113913.mail.gq1.yahoo.com>
Le dimanche 11 septembre 2011 à 20:38 -0700, Kumar S a écrit :
Please dont top post.
> Thanks Neil. I did try with prink(). I do see entries getting aged
> out, but they are not getting deallocated. This seems to be happening
> because of "ref_cnt". When the route entries are added the ref_cnt is
> set to 1. Looks this is causing trouble clearing the entries
> completely. If I set the ref_cnt to 0, I can see it working. Now I'm
> trying to understand whether this is right. Please let me know if you
> have any thoughts on it.
I believe I already explained what was happening.
A tcp socket has a pointer to a dst, so it holds a reference on it, to
make sure no freeing of dst can happen while at least some socket still
can reference dst. (It could reference freed memory and crash)
As soon as the tcp socket will try to transmit some data, the dst will
be checked and we notice its obsolete : We then release the refcount and
dst pointer.
Later, the garbage collector can notice dst refcount is zero and can
free dst.
If you have dormant tcp sockets (no trafic at all), they hold their dst.
A dormant tcp socket has a pretty more expensive memory cost than its
dst. (Socket structure, dentry, inode, and probably in user land a
thread or process, and data)
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Kumar S @ 2011-09-12 6:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neil Horman, netdev
In-Reply-To: <1315806031.3174.16.camel@edumazet-laptop>
----- Original Message -----
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Kumar S <ps2kumar@yahoo.com>
Cc: Neil Horman <nhorman@tuxdriver.com>; netdev <netdev@vger.kernel.org>
Sent: Sunday, September 11, 2011 10:40 PM
Subject: Re: Memory leak in ip_dst_cache
Le dimanche 11 septembre 2011 à 20:38 -0700, Kumar S a écrit :
Please dont top post.
>> Thanks Neil. I did try with prink(). I do see entries getting aged
>> out, but they are not getting deallocated. This seems to be happening
>> because of "ref_cnt". When the route entries are added the ref_cnt is
>> set to 1. Looks this is causing trouble clearing the entries
>> completely. If I set the ref_cnt to 0, I can see it working. Now I'm
>> trying to understand whether this is right. Please let me know if you
>> have any thoughts on it.
>I believe I already explained what was happening.
>A tcp socket has a pointer to a dst, so it holds a reference on it, to
>make sure no freeing of dst can happen while at least some socket still
>can reference dst. (It could reference freed memory and crash)
>As soon as the tcp socket will try to transmit some data, the dst will
>be checked and we notice its obsolete : We then release the refcount and
>dst pointer.
>Later, the garbage collector can notice dst refcount is zero and can
>free dst.
>If you have dormant tcp sockets (no trafic at all), they hold their dst.
>A dormant tcp socket has a pretty more expensive memory cost than its
>dst. (Socket structure, dentry, inode, and probably in user land a
>thread or process, and data)
Thanks Eric for detailed explanation. You did mention this before. What I see is the cache entries related to the TCP sockets are getting cleared, whenever they age out. But the issue we see here is with the broadcast messages such as SMB messages and network neighbor hood messages. They never get freed. There is no traffic to those destinations from our board.
^ permalink raw reply
* Re: Memory leak in ip_dst_cache
From: Eric Dumazet @ 2011-09-12 6:28 UTC (permalink / raw)
To: Kumar S; +Cc: Neil Horman, netdev
In-Reply-To: <1315807643.92529.YahooMailNeo@web113911.mail.gq1.yahoo.com>
Le dimanche 11 septembre 2011 à 23:07 -0700, Kumar S a écrit :
> ----- Original Message -----
> From: Eric Dumazet <eric.dumazet@gmail.com>
> To: Kumar S <ps2kumar@yahoo.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>; netdev <netdev@vger.kernel.org>
> Sent: Sunday, September 11, 2011 10:40 PM
> Subject: Re: Memory leak in ip_dst_cache
>
> Le dimanche 11 septembre 2011 à 20:38 -0700, Kumar S a écrit :
>
> Please dont top post.
>
> >> Thanks Neil. I did try with prink(). I do see entries getting aged
> >> out, but they are not getting deallocated. This seems to be happening
> >> because of "ref_cnt". When the route entries are added the ref_cnt is
> >> set to 1. Looks this is causing trouble clearing the entries
> >> completely. If I set the ref_cnt to 0, I can see it working. Now I'm
> >> trying to understand whether this is right. Please let me know if you
> >> have any thoughts on it.
>
> >I believe I already explained what was happening.
>
> >A tcp socket has a pointer to a dst, so it holds a reference on it, to
> >make sure no freeing of dst can happen while at least some socket still
> >can reference dst. (It could reference freed memory and crash)
>
> >As soon as the tcp socket will try to transmit some data, the dst will
> >be checked and we notice its obsolete : We then release the refcount and
> >dst pointer.
>
> >Later, the garbage collector can notice dst refcount is zero and can
> >free dst.
>
> >If you have dormant tcp sockets (no trafic at all), they hold their dst.
> >A dormant tcp socket has a pretty more expensive memory cost than its
> >dst. (Socket structure, dentry, inode, and probably in user land a
> >thread or process, and data)
>
> Thanks Eric for detailed explanation. You did mention this before.
> What I see is the cache entries related to the TCP sockets are getting
> cleared, whenever they age out. But the issue we see here is with the
> broadcast messages such as SMB messages and network neighbor hood
> messages. They never get freed. There is no traffic to those
> destinations from our board.
What do you mean ? Your box is a router only ?
Those SMB messages are going through it ?
^ permalink raw reply
* Re: [PATCH 03/10] mm: Add support for a filesystem to control swap files
From: Peter Zijlstra @ 2011-09-12 9:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mel Gorman, Linux-MM, Linux-Netdev, Linux-NFS, LKML,
Andrew Morton, David Miller, Trond Myklebust, Neil Brown
In-Reply-To: <20110909133611.GB8155@infradead.org>
On Fri, 2011-09-09 at 09:36 -0400, Christoph Hellwig wrote:
> The equivalent of ->direct_IO should be used for both reads and writes.
So the difference between DIO and swapIO is that swapIO needs the block
map pinned in memory.. So at the very least you'll need those
swap_{activate,deactivate} aops. The read/write-page thingies could
indeed be shared with DIO.
--
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] ipvs: Expose ip_vs_ftp module parameters via sysfs.
From: Krzysztof Wilczynski @ 2011-09-12 9:15 UTC (permalink / raw)
To: Simon Horman; +Cc: Patrick McHardy, netdev
This is to expose "ports" parameter via sysfs so it can be read
at any time in order to determine what port or ports were passed
to the module at the point when it was loaded.
Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
---
net/netfilter/ipvs/ip_vs_ftp.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
index 4490a32..538d74e 100644
--- a/net/netfilter/ipvs/ip_vs_ftp.c
+++ b/net/netfilter/ipvs/ip_vs_ftp.c
@@ -52,8 +52,9 @@
* List of ports (up to IP_VS_APP_MAX_PORTS) to be handled by helper
* First port is set to the default port.
*/
+static unsigned int ports_count = 1;
static unsigned short ports[IP_VS_APP_MAX_PORTS] = {21, 0};
-module_param_array(ports, ushort, NULL, 0);
+module_param_array(ports, ushort, &ports_count, 0444);
MODULE_PARM_DESC(ports, "Ports to monitor for FTP control commands");
@@ -449,7 +450,7 @@ static int __net_init __ip_vs_ftp_init(struct net *net)
if (ret)
goto err_exit;
- for (i=0; i<IP_VS_APP_MAX_PORTS; i++) {
+ for (i = 0; i < ports_count; i++) {
if (!ports[i])
continue;
ret = register_ip_vs_app_inc(net, app, app->protocol, ports[i]);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 03/10] mm: Add support for a filesystem to control swap files
From: Mel Gorman @ 2011-09-12 9:34 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Christoph Hellwig, Linux-MM, Linux-Netdev, Linux-NFS, LKML,
Andrew Morton, David Miller, Trond Myklebust, Neil Brown
In-Reply-To: <1315818285.26517.18.camel@twins>
On Mon, Sep 12, 2011 at 11:04:45AM +0200, Peter Zijlstra wrote:
> On Fri, 2011-09-09 at 09:36 -0400, Christoph Hellwig wrote:
> > The equivalent of ->direct_IO should be used for both reads and writes.
>
> So the difference between DIO and swapIO is that swapIO needs the block
> map pinned in memory.. So at the very least you'll need those
> swap_{activate,deactivate} aops. The read/write-page thingies could
> indeed be shared with DIO.
>
I'm travelling at the moment so it'll be later in the week when I investigate
properly but I agree swap_[de|a]ctivate are still necessary. NFS does not
need to pin a block map but it's still necessary for calling xs_set_memalloc.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 03/10] mm: Add support for a filesystem to control swap files
From: Peter Zijlstra @ 2011-09-12 9:56 UTC (permalink / raw)
To: Mel Gorman
Cc: Christoph Hellwig, Linux-MM, Linux-Netdev, Linux-NFS, LKML,
Andrew Morton, David Miller, Trond Myklebust, Neil Brown
In-Reply-To: <20110912093058.GA3207@suse.de>
On Mon, 2011-09-12 at 10:34 +0100, Mel Gorman wrote:
> On Mon, Sep 12, 2011 at 11:04:45AM +0200, Peter Zijlstra wrote:
> > On Fri, 2011-09-09 at 09:36 -0400, Christoph Hellwig wrote:
> > > The equivalent of ->direct_IO should be used for both reads and writes.
> >
> > So the difference between DIO and swapIO is that swapIO needs the block
> > map pinned in memory.. So at the very least you'll need those
> > swap_{activate,deactivate} aops. The read/write-page thingies could
> > indeed be shared with DIO.
> >
>
> I'm travelling at the moment so it'll be later in the week when I investigate
> properly but I agree swap_[de|a]ctivate are still necessary. NFS does not
> need to pin a block map but it's still necessary for calling xs_set_memalloc.
Right.. but I think the hope was that we could replace the current swap
bmap hackery with this and simplify the normal swap bits. But yeah,
networked filesystems don't really bother with block maps on the client
side ;-)
--
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 v2 6/9] per-cgroup tcp buffers control
From: KAMEZAWA Hiroyuki @ 2011-09-12 10:31 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Eric W. Biederman
In-Reply-To: <4E6A001C.2040600@parallels.com>
On Fri, 9 Sep 2011 09:01:32 -0300
Glauber Costa <glommer@parallels.com> wrote:
> On 09/09/2011 12:12 AM, KAMEZAWA Hiroyuki wrote:
> > On Wed, 7 Sep 2011 01:23:16 -0300
> > Glauber Costa<glommer@parallels.com> wrote:
> >
> >> With all the infrastructure in place, this patch implements
> >> per-cgroup control for tcp memory pressure handling.
> >>
> >> 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>
> >
> > Hmm, then, kmem_cgroup.c is just a caller of plugins implemented
> > by other components ?
>
> Kame,
>
> Refer to my discussion with Greg. How would you feel about it being
> accounted to a single "kernel memory" limit in memcg?
>
Hmm, it's argued that 'cgroup is hard to use, it's difficult!!!'.
Then, if implementation is clean, I think it may be good to add
kmem limit to memcg.
Your and Greg's idea is to have
memory.kmem_limit_in_bytes
?
Thanks,
-Kame
--
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 v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Stanislav Kinsbursky @ 2011-09-12 11:22 UTC (permalink / raw)
To: Trond Myklebust
Cc: Jeff Layton, linux-nfs@vger.kernel.org, Pavel Emelianov,
neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <1315596308.17611.46.camel@lade.trondhjem.org>
09.09.2011 23:25, Trond Myklebust пишет:
> On Fri, 2011-09-09 at 15:01 -0400, Jeff Layton wrote:
>> On Fri, 09 Sep 2011 14:44:34 -0400
>> Trond Myklebust<Trond.Myklebust@netapp.com> wrote:
>>
>>> On Fri, 2011-09-09 at 20:41 +0400, Stanislav Kinsbursky wrote:
>>>> 09.09.2011 18:07, Jeff Layton пишет:
>>>>> On Fri, 09 Sep 2011 16:08:44 +0400
>>>>> Stanislav Kinsbursky<skinsbursky@parallels.com> wrote:
>>>>>
>>>>>> Create rcbind clients or increase rpcbind users counter during RPC service
>>>>>> creation and decrease this counter (and possibly destroy those clients) on RPC
>>>>>> service destruction.
>>>>>>
>>>>>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>>>>>
>>>>>> ---
>>>>>> include/linux/sunrpc/clnt.h | 2 ++
>>>>>> net/sunrpc/rpcb_clnt.c | 2 +-
>>>>>> net/sunrpc/svc.c | 13 +++++++++++--
>>>>>> 3 files changed, 14 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
>>>>>> index db7bcaf..65a8115 100644
>>>>>> --- a/include/linux/sunrpc/clnt.h
>>>>>> +++ b/include/linux/sunrpc/clnt.h
>>>>>> @@ -135,10 +135,12 @@ void rpc_shutdown_client(struct rpc_clnt *);
>>>>>> void rpc_release_client(struct rpc_clnt *);
>>>>>> void rpc_task_release_client(struct rpc_task *);
>>>>>>
>>>>>> +int rpcb_create_local(void);
>>>>>> int rpcb_register(u32, u32, int, unsigned short);
>>>>>> int rpcb_v4_register(const u32 program, const u32 version,
>>>>>> const struct sockaddr *address,
>>>>>> const char *netid);
>>>>>> +void rpcb_put_local(void);
>>>>>> void rpcb_getport_async(struct rpc_task *);
>>>>>>
>>>>>> void rpc_call_start(struct rpc_task *);
>>>>>> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
>>>>>> index b4cc0f1..437ec60 100644
>>>>>> --- a/net/sunrpc/rpcb_clnt.c
>>>>>> +++ b/net/sunrpc/rpcb_clnt.c
>>>>>> @@ -318,7 +318,7 @@ out:
>>>>>> * Returns zero on success, otherwise a negative errno value
>>>>>> * is returned.
>>>>>> */
>>>>>> -static int rpcb_create_local(void)
>>>>>> +int rpcb_create_local(void)
>>>>>> {
>>>>>> static DEFINE_MUTEX(rpcb_create_local_mutex);
>>>>>> int result = 0;
>>>>>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
>>>>>> index 6a69a11..9095c0e 100644
>>>>>> --- a/net/sunrpc/svc.c
>>>>>> +++ b/net/sunrpc/svc.c
>>>>>> @@ -367,8 +367,11 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>>>>>> unsigned int xdrsize;
>>>>>> unsigned int i;
>>>>>>
>>>>>> - if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
>>>>>> + if (rpcb_create_local()< 0)
>>>>>> return NULL;
>>>>>> +
>>>>>> + if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
>>>>>> + goto out_err;
>>>>>> serv->sv_name = prog->pg_name;
>>>>>> serv->sv_program = prog;
>>>>>> serv->sv_nrthreads = 1;
>>>>>> @@ -403,7 +406,7 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>>>>>> GFP_KERNEL);
>>>>>> if (!serv->sv_pools) {
>>>>>> kfree(serv);
>>>>>> - return NULL;
>>>>>> + goto out_err;
>>>>>> }
>>>>>>
>>>>>> for (i = 0; i< serv->sv_nrpools; i++) {
>>>>>> @@ -423,6 +426,10 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>>>>>> svc_unregister(serv);
>>>>>>
>>>>>> return serv;
>>>>>> +
>>>>>> +out_err:
>>>>>> + rpcb_put_local();
>>>>>> + return NULL;
>>>>>> }
>>>>>>
>>>>>> struct svc_serv *
>>>>>> @@ -491,6 +498,8 @@ svc_destroy(struct svc_serv *serv)
>>>>>> svc_unregister(serv);
>>>>>> kfree(serv->sv_pools);
>>>>>> kfree(serv);
>>>>>> +
>>>>>> + rpcb_put_local();
>>>>>> }
>>>>>> EXPORT_SYMBOL_GPL(svc_destroy);
>>>>>>
>>>>>>
>>>>>
>>>>> I don't get it -- what's the advantage of creating rpcbind clients in
>>>>> __svc_create vs. the old way of creating them just before we plan to
>>>>> use them?
>>>>>
>>>>
>>>> The main problem here is not in creation, but in destroying those clients.
>>>> Now rpcbind clients are created during rpcb_register(). I.e. once per every family, program version and so on.
>>>> But can be unregistered for all protocol families by one call. So it's impossible to put reference counting for those clients in the place, where they are created now.
>>>
>>> Could we perhaps set up a 'struct pernet_operations' to create a
>>> destructor for them?
>>>
>>
>> An even easier idea might be to just not take a reference to the
>> rpcbind client for svc_programs that have vs_hidden set on every
>> version.
>
> Isn't the problem that Stanislav is trying to solve that we need to be
> able to register and unregister RPC services to the correct rpcbind
> server, depending on which net namespace we are in?
>
Yes, it is.
I'm going to make rpcbind clients per net namespace.
> My understanding is that the current code will register everything to
> whatever rpcbind server is running in the init net namespace because
> that's what rpcb_create_local() uses.
>
> My suggestion is to use a struct pernet_operations to detect when a net
> namespace is being created or destroyed, so that the rpcbind client code
> knows when to create or destroy a connection to the server that is
> running in that namespace.
>
But as Pavel mentioned already, we can't use netns destructor for rpcbind
clients because they holds netns reference.
That's why we have to untie netns from rpbind clients first.
Another solution is to not increment netns ref counter for rpcbind sockets as,
again, Pavel already mentioned.
But first approach looks clearer from my pow. That's why I'm trying to make
rcpbind client's self-destructible.After achieving this we can just make this
rpcbind clients per netns and then we can virtualize lockd.
I've tried to find some better place for creating rpcbind clients (instead of
__svc_create()). But this place looks like the best one for current solution.
About avoiding of creation of rpcbind clients for nfs 4.* callbacks.
Probably, we can implement init-fini calls for svc_program structure
(rpcb_create_local() and rpcb_put_local() will be used in our case) and then
inherit them for svc_serv. This will allow us to call this hooks only if they
defined and thus avoid rpcbind clients creation for nfs callbacks.
What all of you think about this hook's idea?
> Cheers
> Trond
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* (unknown),
From: Petros Vassiliou @ 2011-09-12 11:42 UTC (permalink / raw)
To: netdev
subscribe netdev
^ permalink raw reply
* Re: [PATCH 03/10] mm: Add support for a filesystem to control swap files
From: Mel Gorman @ 2011-09-12 11:56 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Christoph Hellwig, Linux-MM, Linux-Netdev, Linux-NFS, LKML,
Andrew Morton, David Miller, Trond Myklebust, Neil Brown
In-Reply-To: <1315821369.26517.21.camel@twins>
On Mon, Sep 12, 2011 at 11:56:09AM +0200, Peter Zijlstra wrote:
> On Mon, 2011-09-12 at 10:34 +0100, Mel Gorman wrote:
> > On Mon, Sep 12, 2011 at 11:04:45AM +0200, Peter Zijlstra wrote:
> > > On Fri, 2011-09-09 at 09:36 -0400, Christoph Hellwig wrote:
> > > > The equivalent of ->direct_IO should be used for both reads and writes.
> > >
> > > So the difference between DIO and swapIO is that swapIO needs the block
> > > map pinned in memory.. So at the very least you'll need those
> > > swap_{activate,deactivate} aops. The read/write-page thingies could
> > > indeed be shared with DIO.
> > >
> >
> > I'm travelling at the moment so it'll be later in the week when I investigate
> > properly but I agree swap_[de|a]ctivate are still necessary. NFS does not
> > need to pin a block map but it's still necessary for calling xs_set_memalloc.
>
> Right.. but I think the hope was that we could replace the current swap
> bmap hackery with this and simplify the normal swap bits. But yeah,
> networked filesystems don't really bother with block maps on the client
> side ;-)
I took a look at what was involved with doing the block lookups in
ext4. It's what led to patch 4 of this series because it was necessary that
the filesystem get the same information as the generic handler. It got a
bit messy but looked like it would have worked if I kept at it. I stopped
because I did nt see a major advantage with swap_writepage() looking up
the block map instead of having looked it up in advance with bmap() but
I could have missed something.
--
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 03/10] mm: Add support for a filesystem to control swap files
From: Peter Zijlstra @ 2011-09-12 12:06 UTC (permalink / raw)
To: Mel Gorman
Cc: Christoph Hellwig, Linux-MM, Linux-Netdev, Linux-NFS, LKML,
Andrew Morton, David Miller, Trond Myklebust, Neil Brown
In-Reply-To: <20110912115605.GB3207@suse.de>
On Mon, 2011-09-12 at 12:56 +0100, Mel Gorman wrote:
> I took a look at what was involved with doing the block lookups in
> ext4. It's what led to patch 4 of this series because it was necessary that
> the filesystem get the same information as the generic handler. It got a
> bit messy but looked like it would have worked if I kept at it. I stopped
> because I did nt see a major advantage with swap_writepage() looking up
> the block map instead of having looked it up in advance with bmap() but
> I could have missed something.
IIRC the filesystem folks don't like the bmap thing and would like it to
go away.. could be they changed their minds again though, who knows ;-)
--
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
* [RFC/PATCH] net: add deferred flow cache flush function to be used in xfrm
From: Madalin Bucur @ 2011-09-12 12:17 UTC (permalink / raw)
To: netdev; +Cc: davem, timo.teras, Madalin Bucur
The xfrm garbage collector calls flow_cache_flush() that might sleep.
The xfrm garbage collector can be called from softirq context, such as from
net_rx_action() through ip_forward(). Added flow_cache_flush_deferred()
function that uses the kernel-global work queue to leave the actual
cache flush processing outside the softirq context.
Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
---
include/net/flow.h | 1 +
net/core/flow.c | 12 ++++++++++++
net/xfrm/xfrm_policy.c | 2 +-
3 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index c6d5fe5..7b4bc88 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -188,6 +188,7 @@ extern struct flow_cache_object *flow_cache_lookup(
u8 dir, flow_resolve_t resolver, void *ctx);
extern void flow_cache_flush(void);
+extern void flow_cache_flush_deferred(void);
extern atomic_t flow_cache_genid;
#endif
diff --git a/net/core/flow.c b/net/core/flow.c
index 990703b..4edef63 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -352,6 +352,18 @@ void flow_cache_flush(void)
put_online_cpus();
}
+static void flow_cache_flush_wq(struct work_struct *work)
+{
+ flow_cache_flush();
+}
+
+static DECLARE_WORK(flow_cache_flush_work, flow_cache_flush_wq);
+
+void flow_cache_flush_deferred(void)
+{
+ schedule_work(&flow_cache_flush_work);
+}
+
static int __cpuinit flow_cache_cpu_prepare(struct flow_cache *fc, int cpu)
{
struct flow_cache_percpu *fcp = per_cpu_ptr(fc->percpu, cpu);
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 5ce74a3..62b1af8 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2274,7 +2274,7 @@ static void __xfrm_garbage_collect(struct net *net)
{
struct dst_entry *head, *next;
- flow_cache_flush();
+ flow_cache_flush_deferred();
spin_lock_bh(&xfrm_policy_sk_bundle_lock);
head = xfrm_policy_sk_bundles;
--
1.7.0.1
^ permalink raw reply related
* Re: Using gretap to tunnel layer 2 traffic
From: David Lamparter @ 2011-09-12 12:52 UTC (permalink / raw)
To: John H; +Cc: netdev@vger.kernel.org
In-Reply-To: <1315589104.22676.YahooMailNeo@web45104.mail.sp1.yahoo.com>
On Fri, Sep 09, 2011 at 10:25:04AM -0700, John H wrote:
> [...] All VLANs and physical devices have MTUs of
> 1500. The gretap device has a resultant MTU of 1462, thereby causing the
> bridge device to have an MTU of 1462.
> [...]
> The real question is, however, why is any client able to send a single ICMP
> packet with size 1478 bytes when one of the hops along the way only
> supports 1462 bytes per its MTU? Shouldn't this have been negotiated
> beforehand?
No.
An Ethernet segment needs a single, unbroken, identical MTU at all of
its (packet-sending) participants. Your configuration is invalid; there
is no Ethernet-builtin mechanism to negotiate MTU.
You need to set all devices, hosts and possibly switches to the same MTU
value. (A switch with its default of 1500 isn't a problem as long as it
does not generate packets that large.) A way to do that is by DHCP,
which has a MTU option; that option is however not honoured by all
clients.
Alternatively, you need to change your gretap/bridge MTU to 1500, but
you'll somehow need to make gretap aware of the underlying
fragmentation support, from whereever it may come.
Alter-alternatively, you can use a layer 3 (IP/IPv6) router. IP, unlike
Ethernet, is designed to cope with varying MTUs...
-David
^ 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