* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Linus Torvalds @ 2007-07-24 19:48 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <20070724194046.GD6019@stusta.de>
On Tue, 24 Jul 2007, Adrian Bunk wrote:
>
> > But do we
> > care so much that it's worth inlining something like buffered_rmqueue()?
> >...
>
> Where is the problem with having buffered_rmqueue() inlined?
In this case, it was a pain to just even try to find the call chain, or
read the asm.
I would encourage lots of kernel hackers to read the assembler code gcc
generates. I suspect people being aware of code generation issues (and
writing their code with that in mind) is a *much* bigger performance
impact than gcc inlining random functions.
So maybe I'm old-fashioned and crazy, but "readability of the asm result"
actually is a worthwhile goal. Not because we care directly, but because
I'd like to encourage people to do it, due to the *indirect* benefits.
Linus
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Linus Torvalds @ 2007-07-24 19:45 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Morton, Adrian Bunk, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <p73r6mxsg2o.fsf@bingen.suse.de>
On Tue, 24 Jul 2007, Andi Kleen wrote:
>
> There's probably a --param where it can be tweaked exactly. The
> problem is that --params tend to be very gcc version specific
> and might do something completely different on a newer or
> older version. So it's better not to use them.
I agree wholeheartedly with that sentiment. We've tried at times (because
some gcc snapshots made some *truly* insane choices for a while), and
maybe we still have some around. Not worth the pain.
Linus
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Adrian Bunk @ 2007-07-24 19:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <alpine.LFD.0.999.0707241207290.3607@woody.linux-foundation.org>
On Tue, Jul 24, 2007 at 12:15:48PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 24 Jul 2007, Andrew Morton wrote:
> >
> > fwiw, -fno-inline-functions-called-once (who knew?) takes i386 allnoconfig
> > vmlinux .text from 928360 up to 955362 bytes (27k larger).
> >
> > A surprisingly large increase - I wonder if it did something dumb. It
> > appears to still correctly inline those things which we've manually marked
> > inline. hm.
>
> I think inlining small enough functions is worth it, and the thing is, the
> kernel is actually pretty damn good at having lots of small functions.
> It's one of the few things I really care about from a coding style
> standpoint.
>
> So I'm not surprised that "-fno-inline-functions-called-once" makes things
> larger, because I think it's generally a good idea to inline things that
> are just called once. But it does make things harder to debug, and the
> performance advantages become increasingly small for bigger functions.
>
> And that's a balancing act. Do we care about performance? Yes.
When using CONFIG_CC_OPTIMIZE_FOR_SIZE=y we even actively tell gcc that
we only care about size and do not care about performance...
> But do we
> care so much that it's worth inlining something like buffered_rmqueue()?
>...
Where is the problem with having buffered_rmqueue() inlined?
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Andi Kleen @ 2007-07-24 20:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Adrian Bunk, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <alpine.LFD.0.999.0707241207290.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> So "called once" should probably make the inlining weight bigger (ie
> inline *larger* functions than you would otherwise), it just shouldn't
> make it "infinite". It's not worth it.
There's probably a --param where it can be tweaked exactly. The
problem is that --params tend to be very gcc version specific
and might do something completely different on a newer or
older version. So it's better not to use them.
-Andi
^ permalink raw reply
* [ofa-general] [PATCH] amso1100: QP init bug in amso driver
From: Tom Tucker @ 2007-07-24 19:31 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, OpenFabrics General
Roland:
The guys at UNH found this and fixed it. I'm surprised no
one has hit this before. I guess it only breaks when the
refcount on the QP is non-zero.
Initialize the wait_queue_head_t in the c2_qp structure.
Signed-off-by: Ethan Burns <eaburns@iol.unh.edu>
Acked-by: Tom Tucker <tom@opengridcomputing.com>
---
drivers/infiniband/hw/amso1100/c2_qp.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/amso1100/c2_qp.c b/drivers/infiniband/hw/amso1100/c2_qp.c
index 420c138..01d0786 100644
--- a/drivers/infiniband/hw/amso1100/c2_qp.c
+++ b/drivers/infiniband/hw/amso1100/c2_qp.c
@@ -506,6 +506,7 @@ int c2_alloc_qp(struct c2_dev *c2dev,
qp->send_sgl_depth = qp_attrs->cap.max_send_sge;
qp->rdma_write_sgl_depth = qp_attrs->cap.max_send_sge;
qp->recv_sgl_depth = qp_attrs->cap.max_recv_sge;
+ init_waitqueue_head(&qp->wait);
/* Initialize the SQ MQ */
q_size = be32_to_cpu(reply->sq_depth);
^ permalink raw reply related
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Linus Torvalds @ 2007-07-24 19:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Marcin ??lusarz, Jarek Poplawski, Jean-Baptiste Vignaud,
linux-kernel, shemminger, linux-net, netdev, Thomas Gleixner,
Andrew Morton
In-Reply-To: <20070724094202.GA11610@elte.hu>
On Tue, 24 Jul 2007, Ingo Molnar wrote:
>
> please try the patch below instead.
I'm hoping this is just a "let's see if the behavior changes" patch, not
something that you think should be applied if it fixes something?
This patch looks like it is trying to paper over (rather than fix) some
possible bug in the "->disable" logic. Makes sense as a "let's see if it's
that" kind of thing, but not as a "let's fix it".
Or am I missing something?
Linus
^ permalink raw reply
* Re: [PATCH 00/10] Implement batching skb API
From: jamal @ 2007-07-24 19:28 UTC (permalink / raw)
To: Krishna Kumar2
Cc: davem, gaagaan, general, herbert, jagana, jeff, johnpol, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr, rdreier,
rick.jones2, Robert.Olsson, sri, tgraf, xma
In-Reply-To: <OF782207DD.01F7022B-ON65257322.000F7C16-65257322.0014942E@in.ibm.com>
KK,
On Tue, 2007-24-07 at 09:14 +0530, Krishna Kumar2 wrote:
>
> J Hadi Salim <j.hadi123@gmail.com> wrote on 07/23/2007 06:02:01 PM:
> Actually you have not sent netperf results with prep and without prep.
My results were based on pktgen (which i explained as testing the
driver). I think depending on netperf without further analysis is
simplistic. It was like me doing forwarding tests on these patches.
> > So _which_ non-LLTX driver doesnt do that? ;->
>
> I have no idea since I haven't looked at all drivers. Can you tell which
> all non-LLTX drivers does that ? I stated this as the sole criterea.
The few i have peeked at all do it. I also think the e1000 should be
converted to be non-LLTX. The rest of netdev is screaming to kill LLTX.
> > tun driver doesnt use it either - but i doubt that makes it "bloat"
>
> Adding extra code that is currently not usable (esp from a submission
> point) is bloat.
So far i have converted 3 drivers, 1 of them doesnt use it. Two more
driver conversions are on the way, they will both use it. How is this
bloat again?
A few emails back you said if only IPOIB can use batching then thats
good enough justification.
> > You waltz in, have the luxury of looking at my code, presentations, many
> > discussions with me etc ...
>
> "luxury" ?
> I had implemented the entire thing even before knowing that you
> are working on something similar! and I had sent the first proposal to
> netdev,
I saw your patch at the end of may (or at least 2 weeks after you said
it existed). That patch has very little resemblance to what you just
posted conceptwise or codewise. I could post it if you would give me
permission.
> *after* which you told that you have your own code and presentations (which
> I had never seen earlier - I joined netdev a few months back, earlier I was
> working on RDMA, Infiniband as you know).
I am gonna assume you didnt know of my work - which i have been making
public for about 3 years. Infact i talked about this topic when i
visited your office in 2006 on a day you were not present, so it is
plausible you didnt hear of it.
> And it didn't give me any great
> ideas either, remember I had posted results for E1000 at the time of
> sending the proposals.
In mid-June you sent me a series of patches which included anything from
changing variable names to combining qdisc_restart and about everything
i referred to as being "cosmetic differences" in your posted patches. I
took two of those and incorporated them in. One was an "XXX" in my code
already to allocate the dev->blist
(Commit: bb4464c5f67e2a69ffb233fcf07aede8657e4f63).
The other one was a mechanical removal of the blist being passed
(Commit: 0e9959e5ee6f6d46747c97ca8edc91b3eefa0757).
Some of the others i asked you to defer. For example, the reason i gave
you for not merging any qdisc_restart_combine changes is because i was
waiting for Dave to swallow the qdisc_restart changes i made; otherwise
maintainance becomes extremely painful for me.
Sridhar actually provided a lot more valuable comments and fixes but has
not planted a flag on behalf of the queen of spain like you did.
> However I do give credit in my proposal to you for what
> ideas that your provided (without actual code), and the same I did for other
> people who did the same, like Dave, Sridhar. BTW, you too had discussions with me,
> and I sent some patches to improve your code too,
I incorporated two of your patches and asked for deferal of others.
These patches have now shown up in what you claim as "the difference". I
just call them "cosmetic difference" not to downplay the importance of
having an ethtool interface but because they do not make batching
perform any better. The real differences are those two items. I am
suprised you havent cannibalized those changes as well. I thought you
renamed them to something else; according to your posting:
"This patch will work with drivers updated by Jamal, Matt & Michael Chan
with minor modifications - rename xmit_win to xmit_slots & rename batch
handler". Or maybe thats a "future plan" you have in mind?
> so it looks like a two
> way street to me (and that is how open source works and should).
Open source is a lot more transparent than that.
You posted a question, which was part of your research. I responded and
told you i have patches; you asked me for them and i promptly ported
them from pre-2.6.18 to the latest kernel at the time.
The nature of this batching work is one of performance. So numbers are
important. If you had some strong disagreements on something in the
architecture, then it would be of great value to explain it in a
technical detail - and more importantly to provide some numbers to say
why it is a bad idea. You get numbers by running some tests.
You did none of the above. Your effort has been to produce "your patch"
for whatever reasons. This would not have been problematic to me if it
actually was based within reasons of optimization because the end goal
would have been achieved.
I have deleted the rest of the email because it goes back and forth on
the same points.
I am gonna continue work on the current tree i have. I will put more
time when i get back next week (and hopefully no travel right after).
I will upgrade to Daves tree later when i get the two new drivers in. I
am probably gonna hold on until the new NAPI stuff settles in first. You
are welcome to submit the ipoib changes in. You are also welcome to
co-author with me but you will have to work for it this time.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK
From: Patrick McHardy @ 2007-07-24 19:17 UTC (permalink / raw)
To: Al Boldi; +Cc: Sam Ravnborg, netdev, linux-net, David Miller, Andrew Morton
In-Reply-To: <200707242205.07545.a1426z@gawab.com>
Al Boldi wrote:
> Patrick McHardy wrote:
>
>>Al Boldi wrote:
>>
>>>Patrick McHardy wrote:
>>>
>>>>But I vaguely recall having tried this myself and it broke somewhere,
>>>>maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
>>>>recall anymore. Al, if this also works without removal of
>>>>NF_CONNTRACK_ENABLED, please resend without that part.
>>>
>>>It doesn't. But how about this, if you really can't live without
>>>NF_CONNTRACK_ENBLED:
>>>
>>>==================
>>>--- Kconfig.old 2007-07-09 06:38:52.000000000 +0300
>>>+++ Kconfig 2007-07-24 20:24:27.000000000 +0300
>>>@@ -25,8 +25,7 @@ config NETFILTER_NETLINK_LOG
>>> and is also scheduled to replace the old syslog-based ipt_LOG
>>> and ip6t_LOG modules.
>>>
>>>-# Rename this to NF_CONNTRACK in a 2.6.25
>>>-config NF_CONNTRACK_ENABLED
>>>+config NF_CONNTRACK
>>> tristate "Netfilter connection tracking support"
>>> help
>>> Connection tracking keeps a record of what packets have passed
>>>@@ -40,9 +39,9 @@ config NF_CONNTRACK_ENABLED
>>>
>>> To compile it as a module, choose M here. If unsure, say N.
>>>
>>>-config NF_CONNTRACK
>>>+config NF_CONNTRACK_ENABLED
>>> tristate
>>>- default NF_CONNTRACK_ENABLED
>>>+ default NF_CONNTRACK
>>>
>>> config NF_CT_ACCT
>>> bool "Connection tracking flow accounting"
>>
>>That defeats the only purpose why we kept it.
>
>
> I'm not sure how this would defeat the only purpose. Isn't the purpose of
> this to alias NF_CONNTRACK_ENABLED to NF_CONNTRACK? And as such would yield
> the same result.
The purpose is to avoid forcing people a second time to reconfigure
the conntrack options since we've completed nf_conntrack and removed
ip_conntrack. Previously NF_CONNTRACK was a bool (selecting the new
implementation) and NF_CONNTRACK_ENABLED specified whether to build
either nf_conntrack or ip_conntrack modular/static/not at all. So
old configs only have the information whether to build modular in
NF_CONNTRACK_ENABLED, but NF_CONNTRACK is what actually controls it.
With your change, old configs will still build nf_conntrack properly,
but they will always choose static linking.
> Also, we could leave this as is, and select NF_CONNTRACK_ENABLED instead of
> NF_CONNTRACK.
I guess so, and that would have to select NF_CONNTRACK.
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Linus Torvalds @ 2007-07-24 19:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Adrian Bunk, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <20070724112843.0cc104c2.akpm@linux-foundation.org>
On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> fwiw, -fno-inline-functions-called-once (who knew?) takes i386 allnoconfig
> vmlinux .text from 928360 up to 955362 bytes (27k larger).
>
> A surprisingly large increase - I wonder if it did something dumb. It
> appears to still correctly inline those things which we've manually marked
> inline. hm.
I think inlining small enough functions is worth it, and the thing is, the
kernel is actually pretty damn good at having lots of small functions.
It's one of the few things I really care about from a coding style
standpoint.
So I'm not surprised that "-fno-inline-functions-called-once" makes things
larger, because I think it's generally a good idea to inline things that
are just called once. But it does make things harder to debug, and the
performance advantages become increasingly small for bigger functions.
And that's a balancing act. Do we care about performance? Yes. But do we
care so much that it's worth inlining something like buffered_rmqueue()?
So I would not be surprised if "-fno-inline-functions-called-once" will
disable *all* the inlining heuristics, and say "oh, it's not an inline
function, and it's only called once, so we won't inline it at all".
So "called once" should probably make the inlining weight bigger (ie
inline *larger* functions than you would otherwise), it just shouldn't
make it "infinite". It's not worth it.
Linus
^ permalink raw reply
* Re: [PATCH] Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK
From: Al Boldi @ 2007-07-24 19:05 UTC (permalink / raw)
To: Patrick McHardy
Cc: Sam Ravnborg, netdev, linux-net, David Miller, Andrew Morton
In-Reply-To: <46A6387D.1030601@trash.net>
Patrick McHardy wrote:
> Al Boldi wrote:
> > Patrick McHardy wrote:
> >>But I vaguely recall having tried this myself and it broke somewhere,
> >>maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
> >>recall anymore. Al, if this also works without removal of
> >>NF_CONNTRACK_ENABLED, please resend without that part.
> >
> > It doesn't. But how about this, if you really can't live without
> > NF_CONNTRACK_ENBLED:
> >
> > ==================
> > --- Kconfig.old 2007-07-09 06:38:52.000000000 +0300
> > +++ Kconfig 2007-07-24 20:24:27.000000000 +0300
> > @@ -25,8 +25,7 @@ config NETFILTER_NETLINK_LOG
> > and is also scheduled to replace the old syslog-based ipt_LOG
> > and ip6t_LOG modules.
> >
> > -# Rename this to NF_CONNTRACK in a 2.6.25
> > -config NF_CONNTRACK_ENABLED
> > +config NF_CONNTRACK
> > tristate "Netfilter connection tracking support"
> > help
> > Connection tracking keeps a record of what packets have passed
> > @@ -40,9 +39,9 @@ config NF_CONNTRACK_ENABLED
> >
> > To compile it as a module, choose M here. If unsure, say N.
> >
> > -config NF_CONNTRACK
> > +config NF_CONNTRACK_ENABLED
> > tristate
> > - default NF_CONNTRACK_ENABLED
> > + default NF_CONNTRACK
> >
> > config NF_CT_ACCT
> > bool "Connection tracking flow accounting"
>
> That defeats the only purpose why we kept it.
I'm not sure how this would defeat the only purpose. Isn't the purpose of
this to alias NF_CONNTRACK_ENABLED to NF_CONNTRACK? And as such would yield
the same result.
Also, we could leave this as is, and select NF_CONNTRACK_ENABLED instead of
NF_CONNTRACK.
Thanks!
--
Al
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Andrew Morton @ 2007-07-24 18:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Adrian Bunk, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <alpine.LFD.0.999.0707241113180.3607@woody.linux-foundation.org>
On Tue, 24 Jul 2007 11:14:21 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Tue, 24 Jul 2007, Adrian Bunk wrote:
> >
> > buffered_rmqueue() and prep_new_page() are static functions with only
> > one caller each, and for the normal non-debug case it's a really nice
> > optimization to have them inlined automatically.
>
> I'm not at all sure I agree.
>
> Inlining big functions doesn't actually tend to generally generate any
> better code, so if gcc's logic is "single callsite - always inline", then
> that logic is likely not right.
>
fwiw, -fno-inline-functions-called-once (who knew?) takes i386 allnoconfig
vmlinux .text from 928360 up to 955362 bytes (27k larger).
A surprisingly large increase - I wonder if it did something dumb. It
appears to still correctly inline those things which we've manually marked
inline. hm.
It would be nice to defeat the autoinlining for debug purposes though.
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Linus Torvalds @ 2007-07-24 18:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Mike Galbraith, Alexey Dobriyan, linux-kernel, netdev,
Christoph Lameter
In-Reply-To: <20070724092839.f0556948.akpm@linux-foundation.org>
On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> I guess this was the bug:
Looks very likely to me. Mike, Alexey, does this fix things for you?
Linus
^ permalink raw reply
* RE: NET_DMA: where do we ever call dma_skb_copy_datagram_iovec() with NULL pinned_list?
From: Nelson, Shannon @ 2007-07-24 18:14 UTC (permalink / raw)
To: Al Viro, netdev; +Cc: Leech, Christopher, Andrew Grover
In-Reply-To: <20070721034829.GL21668@ftp.linux.org.uk>
Al Viro:
>
> AFAICS, all callers of dma_skb_copy_datagram_iovec()
>are either
> * recursive for fragments, pass pinned_list unchanged or
> * called from tcp, with pinned_list coming from
>tp->ucopy.pinned_list and only when tp->ucopy.dma_chan is non-NULL.
>
>Now, all non-NULL assignments to ->dma_chan have the same form:
> if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
> tp->ucopy.dma_chan = get_softnet_dma();
>IOW, if ->ucopy.pinned_list stays NULL, ->ucopy.dma_chan will
>do the same.
>
>Moreover, any place that resets ->ucopy.pinned_list will also reset
>->ucopy.dma_chan.
>
>IOW, we can't ever get non-NULL tp->ucopy.dma_chan while
>tp->ucopy.pinned_list
>is NULL. So how can we ever get to the dma_memcpy_to_kernel_iovec()?
It looks like this is "extra" code. The history seems to be that it was
thought to be useful for internal copying, perhaps for smbfs or iSCSI,
as the comment suggests. However, since no one is using it, it can
probably come out. If there is no argument, I'll post a patch to remove
it.
sln
--
======================================================================
Mr. Shannon Nelson LAN Access Division, Intel Corp.
Shannon.Nelson@intel.com I don't speak for Intel
(503) 712-7659 Parents can't afford to be squeamish.
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Linus Torvalds @ 2007-07-24 18:14 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <20070724175951.GC6019@stusta.de>
On Tue, 24 Jul 2007, Adrian Bunk wrote:
>
> buffered_rmqueue() and prep_new_page() are static functions with only
> one caller each, and for the normal non-debug case it's a really nice
> optimization to have them inlined automatically.
I'm not at all sure I agree.
Inlining big functions doesn't actually tend to generally generate any
better code, so if gcc's logic is "single callsite - always inline", then
that logic is likely not right.
Linus
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Adrian Bunk @ 2007-07-24 17:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Alexey Dobriyan, linux-kernel, netdev
In-Reply-To: <alpine.LFD.0.999.0707231415511.3607@woody.linux-foundation.org>
On Mon, Jul 23, 2007 at 02:28:11PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 23 Jul 2007, Andrew Morton wrote:
> >
> > It'd be nice to get a clean trace. Are you able to obtain the full
> > trace with CONFIG_FRAME_POINTER=y?
>
> If you are talking about
>
> http://userweb.kernel.org/~akpm/dsc03659.jpg
>
> then I think that _is_ a full trace. It's certainly not very messy, and it
> seems accurate. It's just that inlining makes it much harder to see the
> call-graphs, but that's what inlining does..
>
> For example, missing from the call graph is
>
> get_page_from_freelist ->
> buffered_rmqueue -> [ missing - inlined ]
> prep_new_page -> [ missing - inlined ]
> prep_zero_page -> [ missing - inlined ]
> clear_highpage -> [ missing - inlined ]
> kmap_atomic -> [ missing - tailcall ]
> kmap_atomic_prot
>
> but I'm pretty sure the call trace is good (and I'm also pretty sure gcc
> is overly aggressive at inlining, and that it causes us pain for
> debugging, but whatever)
>...
For prep_zero_page() and clear_highpage() we can't blame gcc since we
force gcc to always inline them.
buffered_rmqueue() and prep_new_page() are static functions with only
one caller each, and for the normal non-debug case it's a really nice
optimization to have them inlined automatically. But it might make sense
to add -fno-inline-functions-called-once to the CFLAGS depending on some
debug option?
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK
From: Patrick McHardy @ 2007-07-24 17:35 UTC (permalink / raw)
To: Al Boldi; +Cc: Sam Ravnborg, netdev, linux-net, David Miller, Andrew Morton
In-Reply-To: <200707242031.58910.a1426z@gawab.com>
Al Boldi wrote:
> Patrick McHardy wrote:
>
>>But I vaguely recall having tried this myself and it broke somewhere,
>>maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
>>recall anymore. Al, if this also works without removal of
>>NF_CONNTRACK_ENABLED, please resend without that part.
>
>
> It doesn't. But how about this, if you really can't live without
> NF_CONNTRACK_ENBLED:
>
> ==================
> --- Kconfig.old 2007-07-09 06:38:52.000000000 +0300
> +++ Kconfig 2007-07-24 20:24:27.000000000 +0300
> @@ -25,8 +25,7 @@ config NETFILTER_NETLINK_LOG
> and is also scheduled to replace the old syslog-based ipt_LOG
> and ip6t_LOG modules.
>
> -# Rename this to NF_CONNTRACK in a 2.6.25
> -config NF_CONNTRACK_ENABLED
> +config NF_CONNTRACK
> tristate "Netfilter connection tracking support"
> help
> Connection tracking keeps a record of what packets have passed
> @@ -40,9 +39,9 @@ config NF_CONNTRACK_ENABLED
>
> To compile it as a module, choose M here. If unsure, say N.
>
> -config NF_CONNTRACK
> +config NF_CONNTRACK_ENABLED
> tristate
> - default NF_CONNTRACK_ENABLED
> + default NF_CONNTRACK
>
> config NF_CT_ACCT
> bool "Connection tracking flow accounting"
That defeats the only purpose why we kept it. How about we change this
once we remove it, in 2.6.25?
^ permalink raw reply
* Re: [PATCH] Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK
From: Al Boldi @ 2007-07-24 17:31 UTC (permalink / raw)
To: Patrick McHardy
Cc: Sam Ravnborg, netdev, linux-net, David Miller, Andrew Morton
In-Reply-To: <46A62FB0.2090405@trash.net>
Patrick McHardy wrote:
> Sam Ravnborg wrote:
> > On Tue, Jul 24, 2007 at 08:36:33AM +0300, Al Boldi wrote:
> >>Replaces NF_CONNTRACK_ENABLED with NF_CONNTRACK and selects it for
> >>NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6
> >>
> >>This exposes IPv4/6 connection tracking options for easier Kconfig
> >> setup.
> >>
> >>Signed-off-by: Al Boldi <a1426z@gawab.com>
> >>Cc: David Miller <davem@davemloft.net>
> >>Cc: Sam Ravnborg <sam@ravnborg.org>
> >>Cc: Andrew Morton <akpm@linux-foundation.org>
> >>---
> >>--- a/net/netfilter/Kconfig 2007-07-09 06:38:52.000000000 +0300
> >>+++ b/net/netfilter/Kconfig 2007-07-24 08:28:06.000000000 +0300
> >>@@ -25,8 +25,7 @@ config NETFILTER_NETLINK_LOG
> >> and is also scheduled to replace the old syslog-based ipt_LOG
> >> and ip6t_LOG modules.
> >>
> >>-# Rename this to NF_CONNTRACK in a 2.6.25
> >>-config NF_CONNTRACK_ENABLED
> >>+config NF_CONNTRACK
>
> We kept this mainly for an easier upgrade. As the comment states, it
> should go in 2.6.25, at which time all people having reconfigured
> their kernel at least once since ip_conntrack was removed will have
> the NF_CONNTRACK option set to the same value as NF_CONNTRACK_ENABLED.
>
> >>--- a/net/ipv4/netfilter/Kconfig 2007-07-09 06:38:50.000000000 +0300
> >>+++ b/net/ipv4/netfilter/Kconfig 2007-07-24 08:27:39.000000000 +0300
> >>@@ -7,7 +7,7 @@ menu "IP: Netfilter Configuration"
> >>
> >> config NF_CONNTRACK_IPV4
> >> tristate "IPv4 connection tracking support (required for NAT)"
> >>- depends on NF_CONNTRACK
> >>+ select NF_CONNTRACK
> >> ---help---
> >> Connection tracking keeps a record of what packets have passed
> >> through your machine, in order to figure out how they are related
> >>--- a/net/ipv6/netfilter/Kconfig 2007-07-09 06:38:51.000000000 +0300
> >>+++ b/net/ipv6/netfilter/Kconfig 2007-07-24 08:27:54.000000000 +0300
> >>@@ -7,7 +7,8 @@ menu "IPv6: Netfilter Configuration (EXP
> >>
> >> config NF_CONNTRACK_IPV6
> >> tristate "IPv6 connection tracking support (EXPERIMENTAL)"
> >>- depends on INET && IPV6 && EXPERIMENTAL && NF_CONNTRACK
> >>+ depends on INET && IPV6 && EXPERIMENTAL
> >>+ select NF_CONNTRACK
> >> ---help---
> >> Connection tracking keeps a record of what packets have passed
> >> through your machine, in order to figure out how they are related
> >
> > This change looks wrong.
> > Due to the reverse nature of "select" kconfig cannot fulfill the
> > dependencies of selected symbols. So as a rule of thumb select should
> > only select symbols with no menu and no dependencies to avoid some of
> > the
> > problems that have popped up during the last months.
>
> In this case it looks OK since the dependencies of IPv4 connection
> tracking are (besides NF_CONNTRACK) are superset of those of
> nf_conntrack.
>
> But I vaguely recall having tried this myself and it broke somewhere,
> maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
> recall anymore. Al, if this also works without removal of
> NF_CONNTRACK_ENABLED, please resend without that part.
It doesn't. But how about this, if you really can't live without
NF_CONNTRACK_ENBLED:
==================
--- Kconfig.old 2007-07-09 06:38:52.000000000 +0300
+++ Kconfig 2007-07-24 20:24:27.000000000 +0300
@@ -25,8 +25,7 @@ config NETFILTER_NETLINK_LOG
and is also scheduled to replace the old syslog-based ipt_LOG
and ip6t_LOG modules.
-# Rename this to NF_CONNTRACK in a 2.6.25
-config NF_CONNTRACK_ENABLED
+config NF_CONNTRACK
tristate "Netfilter connection tracking support"
help
Connection tracking keeps a record of what packets have passed
@@ -40,9 +39,9 @@ config NF_CONNTRACK_ENABLED
To compile it as a module, choose M here. If unsure, say N.
-config NF_CONNTRACK
+config NF_CONNTRACK_ENABLED
tristate
- default NF_CONNTRACK_ENABLED
+ default NF_CONNTRACK
config NF_CT_ACCT
bool "Connection tracking flow accounting"
==================
Thanks!
--
Al
^ permalink raw reply
* Re: specifying scopid's for link-local IPv6 addrs
From: Rick Jones @ 2007-07-24 17:23 UTC (permalink / raw)
To: Linux Network Development list; +Cc: Bill Fink
In-Reply-To: <46A63327.6010705@hp.com>
>> You must explicitly specify the desired interface. For example,
>> on my test system, the correct interface is eth6 which is interface 8
>> (lo eth0 eth1 eth2 ... eth5 eth6). Here is an example nuttcp test
>> specifying interface 8:
>>
>> chance% nuttcp -P5100 fe80::202:b3ff:fed4:cd1%8
>> 1178.5809 MB / 10.02 sec = 986.2728 Mbps 12 %TX 15 %RX
>>
>> nuttcp uses getaddrinfo() which parses the "%<ifindex>" field,
>> and then copies the sin6_scope_id from the res structure to the
>> server's sockaddr_in6 structure before initiating the connect().
>
>
> OK, I'll give that a quick try with netperf:
>
> [root@hpcpc106 ~]# netperf -H 192.168.2.107 -c -C -i 30,3 -- -s 1M -S 1M
> -m 64K -H fe80::207:43ff:fe05:9d%2
> TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to
> fe80::207:43ff:fe05:9d%2 (fe80::207:43ff:fe05:9d) port 0 AF_INET6 :
> +/-2.5% @ 99% conf.
>
> Cool - it establishes the data connection just fine.
Well, I spoke too soon - while it got me past my EINVAL, the connection
establishement timed-out. Either I picked the wrong value for n, or I may yet
need to make some tweaks to netperf.
rick jones
^ permalink raw reply
* Re: specifying scopid's for link-local IPv6 addrs
From: Sridhar Samudrala @ 2007-07-24 17:28 UTC (permalink / raw)
To: Rick Jones; +Cc: Bill Fink, Linux Network Development list
In-Reply-To: <46A63327.6010705@hp.com>
On Tue, 2007-07-24 at 10:13 -0700, Rick Jones wrote:
> > Rick,
> >
> > I don't see any way around this. For example, on one of my test
> > systems, I have the following link local routes:
> >
> > chance% netstat -A inet6 -rn | grep fe80::/64
> > fe80::/64 :: U 256 0 0 eth0
> > fe80::/64 :: U 256 0 0 eth2
> > fe80::/64 :: U 256 0 0 eth3
> > fe80::/64 :: U 256 0 0 eth4
> > fe80::/64 :: U 256 0 0 eth5
> > fe80::/64 :: U 256 0 0 eth6
> >
> > So if I want to run a link local test to fe80::202:b3ff:fed4:cd1,
> > the system has no way to choose which is the correct interface to
> > use for the test, and will give an error if the interface isn't
> > specified.
>
> Yeah, I was wondering about that. I'm not sure if the attempts on "those other
> OSes" happened to involve multiple interfaces or not. Even so, it "feels"
> unpleasant for an application to deal with and I wonder if there is a way for a
> stack to deal with it on the application's behalf. I guess that might involve
> some sort of layer violation between neightbor discovery and routing (typing
> while I think about things I know little about...)
>
> Is there RFC chapter and verse I might read about routing with multiple
> link-local's on a system?
>
> > You must explicitly specify the desired interface. For example,
> > on my test system, the correct interface is eth6 which is interface 8
> > (lo eth0 eth1 eth2 ... eth5 eth6). Here is an example nuttcp test
> > specifying interface 8:
> >
> > chance% nuttcp -P5100 fe80::202:b3ff:fed4:cd1%8
> > 1178.5809 MB / 10.02 sec = 986.2728 Mbps 12 %TX 15 %RX
> >
> > nuttcp uses getaddrinfo() which parses the "%<ifindex>" field,
> > and then copies the sin6_scope_id from the res structure to the
> > server's sockaddr_in6 structure before initiating the connect().
>
> OK, I'll give that a quick try with netperf:
>
> [root@hpcpc106 ~]# netperf -H 192.168.2.107 -c -C -i 30,3 -- -s 1M -S 1M -m 64K
> -H fe80::207:43ff:fe05:9d%2
We can even specify the interface name instead of the interface index
<link-local>%ethX
getaddrinfo() uses if_nametoindex() internally to get the index.
Thanks
Sridhar
> TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to fe80::207:43ff:fe05:9d%2
> (fe80::207:43ff:fe05:9d) port 0 AF_INET6 : +/-2.5% @ 99% conf.
>
> Cool - it establishes the data connection just fine.
>
>
> To further demonstrate my ignorance :) is that %n suffix something one might
> expect in most/all getaddrinfo()'s or is that unique to the one in Linux?
>
> rick jones
> -
> 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_DMA: where do we ever call dma_skb_copy_datagram_iovec() with NULL pinned_list?
From: Andrew Grover @ 2007-07-24 17:24 UTC (permalink / raw)
To: Al Viro, shannon.nelson; +Cc: netdev, christopher.leech
In-Reply-To: <20070721034829.GL21668@ftp.linux.org.uk>
On 7/20/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> AFAICS, all callers of dma_skb_copy_datagram_iovec()
> are either
> * recursive for fragments, pass pinned_list unchanged or
> * called from tcp, with pinned_list coming from
> tp->ucopy.pinned_list and only when tp->ucopy.dma_chan is non-NULL.
>
> Now, all non-NULL assignments to ->dma_chan have the same form:
> if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
> tp->ucopy.dma_chan = get_softnet_dma();
> IOW, if ->ucopy.pinned_list stays NULL, ->ucopy.dma_chan will do the same.
>
> Moreover, any place that resets ->ucopy.pinned_list will also reset
> ->ucopy.dma_chan.
>
> IOW, we can't ever get non-NULL tp->ucopy.dma_chan while tp->ucopy.pinned_list
> is NULL. So how can we ever get to the dma_memcpy_to_kernel_iovec()?
Shannon what do you think? Is this a bug, or does it no longer support
non-userspace iovecs?
Thanks -- Andy
^ permalink raw reply
* Re: specifying scopid's for link-local IPv6 addrs
From: Rick Jones @ 2007-07-24 17:13 UTC (permalink / raw)
To: Bill Fink; +Cc: Linux Network Development list
In-Reply-To: <20070724030115.3208229d.billfink@mindspring.com>
> Rick,
>
> I don't see any way around this. For example, on one of my test
> systems, I have the following link local routes:
>
> chance% netstat -A inet6 -rn | grep fe80::/64
> fe80::/64 :: U 256 0 0 eth0
> fe80::/64 :: U 256 0 0 eth2
> fe80::/64 :: U 256 0 0 eth3
> fe80::/64 :: U 256 0 0 eth4
> fe80::/64 :: U 256 0 0 eth5
> fe80::/64 :: U 256 0 0 eth6
>
> So if I want to run a link local test to fe80::202:b3ff:fed4:cd1,
> the system has no way to choose which is the correct interface to
> use for the test, and will give an error if the interface isn't
> specified.
Yeah, I was wondering about that. I'm not sure if the attempts on "those other
OSes" happened to involve multiple interfaces or not. Even so, it "feels"
unpleasant for an application to deal with and I wonder if there is a way for a
stack to deal with it on the application's behalf. I guess that might involve
some sort of layer violation between neightbor discovery and routing (typing
while I think about things I know little about...)
Is there RFC chapter and verse I might read about routing with multiple
link-local's on a system?
> You must explicitly specify the desired interface. For example,
> on my test system, the correct interface is eth6 which is interface 8
> (lo eth0 eth1 eth2 ... eth5 eth6). Here is an example nuttcp test
> specifying interface 8:
>
> chance% nuttcp -P5100 fe80::202:b3ff:fed4:cd1%8
> 1178.5809 MB / 10.02 sec = 986.2728 Mbps 12 %TX 15 %RX
>
> nuttcp uses getaddrinfo() which parses the "%<ifindex>" field,
> and then copies the sin6_scope_id from the res structure to the
> server's sockaddr_in6 structure before initiating the connect().
OK, I'll give that a quick try with netperf:
[root@hpcpc106 ~]# netperf -H 192.168.2.107 -c -C -i 30,3 -- -s 1M -S 1M -m 64K
-H fe80::207:43ff:fe05:9d%2
TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to fe80::207:43ff:fe05:9d%2
(fe80::207:43ff:fe05:9d) port 0 AF_INET6 : +/-2.5% @ 99% conf.
Cool - it establishes the data connection just fine.
To further demonstrate my ignorance :) is that %n suffix something one might
expect in most/all getaddrinfo()'s or is that unique to the one in Linux?
rick jones
^ permalink raw reply
* Re: [PATCH]: revised make xfrm_audit_log more generic patch
From: Steve Grubb @ 2007-07-24 17:10 UTC (permalink / raw)
To: Joy Latten; +Cc: netdev, linux-audit, davem
In-Reply-To: <1185294806.15699.367.camel@faith.austin.ibm.com>
On Tuesday 24 July 2007 12:33:26 pm Joy Latten wrote:
> > It also wouldn't hurt to change the text being sent to this function to
> > have a hyphen instead of a space, so "SPD delete" becomes "SPD-delete".
> > This keeps the parser happy.
>
> Steve, more for my education, should all entries have this sort of
> syntax, that is, a hyphen in it?
Only if its something that is important to have associated in reports. More
that 1 or 2 hyphens is probably not good.
> I imagine some entries might be a bit more wordy and so I was wondering
> ahead of time how to do it.
The audit logs should be short as possible but contain everything necessary.
You can have language in the record that makes it more understandable for
people reading the raw record, but it won't necessarily be picked up by
report parsers for searching or presentation.
If you want me to help review the choices, let me know offline and we can work
through it.
-Steve
^ permalink raw reply
* Re: [PATCH][30/37] Clean up duplicate includes in net/netfilter/
From: Jesper Juhl @ 2007-07-24 16:59 UTC (permalink / raw)
To: Patrick McHardy
Cc: Linux Kernel Mailing List, Andrew Morton, netdev, David S Miller,
Harald Welte, netfilter-devel, Rusty Russell, James Morris,
Netfilter Core Team, Bart De Schuymer
In-Reply-To: <46A61B32.90302@trash.net>
On 24/07/07, Patrick McHardy <kaber@trash.net> wrote:
> Jesper Juhl wrote:
> > This patch cleans up duplicate includes in
> > net/netfilter/
>
>
> I've queued this one and the bridge-netfilter patch (27/37), thanks
> Jesper.
>
Thanks for the feedback Patrick.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [PATCH] Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK
From: Patrick McHardy @ 2007-07-24 16:58 UTC (permalink / raw)
To: Al Boldi; +Cc: Sam Ravnborg, netdev, linux-net, David Miller, Andrew Morton
In-Reply-To: <20070724055208.GB12946@uranus.ravnborg.org>
Sam Ravnborg wrote:
> On Tue, Jul 24, 2007 at 08:36:33AM +0300, Al Boldi wrote:
>
>>Replaces NF_CONNTRACK_ENABLED with NF_CONNTRACK and selects it for
>>NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6
>>
>>This exposes IPv4/6 connection tracking options for easier Kconfig setup.
>>
>>Signed-off-by: Al Boldi <a1426z@gawab.com>
>>Cc: David Miller <davem@davemloft.net>
>>Cc: Sam Ravnborg <sam@ravnborg.org>
>>Cc: Andrew Morton <akpm@linux-foundation.org>
>>---
>>--- a/net/netfilter/Kconfig 2007-07-09 06:38:52.000000000 +0300
>>+++ b/net/netfilter/Kconfig 2007-07-24 08:28:06.000000000 +0300
>>@@ -25,8 +25,7 @@ config NETFILTER_NETLINK_LOG
>> and is also scheduled to replace the old syslog-based ipt_LOG
>> and ip6t_LOG modules.
>>
>>-# Rename this to NF_CONNTRACK in a 2.6.25
>>-config NF_CONNTRACK_ENABLED
>>+config NF_CONNTRACK
We kept this mainly for an easier upgrade. As the comment states, it
should go in 2.6.25, at which time all people having reconfigured
their kernel at least once since ip_conntrack was removed will have
the NF_CONNTRACK option set to the same value as NF_CONNTRACK_ENABLED.
>>--- a/net/ipv4/netfilter/Kconfig 2007-07-09 06:38:50.000000000 +0300
>>+++ b/net/ipv4/netfilter/Kconfig 2007-07-24 08:27:39.000000000 +0300
>>@@ -7,7 +7,7 @@ menu "IP: Netfilter Configuration"
>>
>> config NF_CONNTRACK_IPV4
>> tristate "IPv4 connection tracking support (required for NAT)"
>>- depends on NF_CONNTRACK
>>+ select NF_CONNTRACK
>> ---help---
>> Connection tracking keeps a record of what packets have passed
>> through your machine, in order to figure out how they are related
>>--- a/net/ipv6/netfilter/Kconfig 2007-07-09 06:38:51.000000000 +0300
>>+++ b/net/ipv6/netfilter/Kconfig 2007-07-24 08:27:54.000000000 +0300
>>@@ -7,7 +7,8 @@ menu "IPv6: Netfilter Configuration (EXP
>>
>> config NF_CONNTRACK_IPV6
>> tristate "IPv6 connection tracking support (EXPERIMENTAL)"
>>- depends on INET && IPV6 && EXPERIMENTAL && NF_CONNTRACK
>>+ depends on INET && IPV6 && EXPERIMENTAL
>>+ select NF_CONNTRACK
>> ---help---
>> Connection tracking keeps a record of what packets have passed
>> through your machine, in order to figure out how they are related
>>
>
> This change looks wrong.
> Due to the reverse nature of "select" kconfig cannot fulfill the dependencies
> of selected symbols. So as a rule of thumb select should only select
> symbols with no menu and no dependencies to avoid some of the
> problems that have popped up during the last months.
In this case it looks OK since the dependencies of IPv4 connection
tracking are (besides NF_CONNTRACK) are superset of those of
nf_conntrack.
But I vaguely recall having tried this myself and it broke somewhere,
maybe it was because of the NF_CONNTRACK_ENABLED option, I can't
recall anymore. Al, if this also works without removal of
NF_CONNTRACK_ENABLED, please resend without that part.
^ permalink raw reply
* Re: [PATCH 0/2] netxen: bug fixes for multiport adapters
From: Dhananjay Phadke @ 2007-07-24 16:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <20070720190749.535704712@netxen.com>
Jeff,
Any chance of these patches getting committed soon?
Thanks,
-Dhananjay Phadke
On 7/21/07, dhananjay@netxen.com <dhananjay@netxen.com> wrote:
> These patches include fix for problem with 2nd port of multiport adapters
> on IBM blades. Also improves interrupt handling for multiport adapters
> avoiding interrupt flood after interrupt is down.
>
> Generated against upstream-fixes.
>
> drivers/net/netxen/netxen_nic.h | 3 +-
> drivers/net/netxen/netxen_nic_main.c | 85 +++++++++++++++---------------
> 2 files changed, 43 insertions(+), 45 deletions(-)
>
> --
> -
> 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
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