> Or, is the concern more about trying to time-slice the results in a
> fairly granular way and expecting accurate results then?
Usually the later. It's especially important for divisions. You want
both divisor and dividend to be in the same time slice, otherwise
the result usually doesn't make a
> > Don't use it. It's misleading on a out-of-order CPU because you don't
> > know if it's actually limiting anything.
> >
> > If you want useful bottleneck data use --topdown.
>
> So running again, this time with the below params, I got this output
> where all the right most column is colored red
On Thu, Oct 15, 2020 at 05:53:40PM +0300, Or Gerlitz wrote:
> Hi,
>
> Earlier Intel processors (e.g E5-2650) support the more of classical
> two stall events (for backend and frontend [1]) and then perf shows
> the nice measure of stalled cycles per instruction - e.g here where we
> have IPC of 0.
> > I'm not sure if size is that great an heuristic. The dedup algorithm should
> > work in any case even if you don't order by size, right?
>
> Consider two metrics:
> - metric 1 with events {A,B}
> - metric 2 with events {A,B,C,D}
> If the list isn't sorted then as the matching takes the first
On Thu, May 07, 2020 at 10:36:21PM -0700, Ian Rogers wrote:
> If allocated, perf_pkg_mask and metric_events need freeing.
All these patches at the beginning look like straight forward
bug fixes and are really independent of the new features.
For them
Reviewed-by: Andi Kleen
>
> Sign
> static struct evsel *find_evsel_group(struct evlist *perf_evlist,
> struct expr_parse_ctx *pctx,
> + bool has_constraint,
> struct evsel **metric_events,
>
On Thu, May 07, 2020 at 10:36:27PM -0700, Ian Rogers wrote:
> When adding event groups to the group list, insert them in size order.
> This performs an insertion sort on the group list. By placing the
> largest groups at the front of the group list it is possible to see if a
> larger group contains
This seems like a independent bug fix and should probably
be pushed independently of the rest.
Perhaps add a Fixes: tag.
Reviewed-by: Andi Kleen
On Thu, May 07, 2020 at 10:36:16PM -0700, Ian Rogers wrote:
> On a CPU like skylakex an uncore_iio_0 PMU may alias with
> uncore_iio_free_run
On Thu, May 07, 2020 at 10:36:15PM -0700, Ian Rogers wrote:
> Metric groups contain metrics. Metrics create groups of events to
> ideally be scheduled together. Often metrics refer to the same events,
> for example, a cache hit and cache miss rate. Using separate event
> groups means these metrics
> > - without this change events within a metric may get scheduled
> > together, after they may appear as part of a larger group and be
> > multiplexed at different times, lowering accuracy - however, less
> > multiplexing may compensate for this.
>
> I agree the heuristic in this patch set
On Thu, May 07, 2020 at 01:14:29AM -0700, Ian Rogers wrote:
> Metric groups contain metrics. Metrics create groups of events to
> ideally be scheduled together. Often metrics refer to the same events,
> for example, a cache hit and cache miss rate. Using separate event
> groups means these metrics
> > Reading csum_partial/csum_fold, seems like after calculation of
> > checksum (so-called unfolded checksum), it is supposed to be passed
> > into csum_fold() to convert it into 16-bit one and invert.
Yes, you always need to fold at the end.
The low level code does fold sometimes, but not alway
From: Andi Kleen
ping_v4_net_ops references init functions, so needs to be __initdata.
ping_proc_exit is then referenced from __initdata, so also needs
to be __init.
Signed-off-by: Andi Kleen
---
net/ipv4/ping.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4
> I wonder if there is some way to use the split format for the
> intermediate files, but then for the very final link bring them all in
> and make the end result be a traditional single binary. I'm not
> talking the separate "dwp" package that packs multiple dwo files into
> one, but to actually l
On Mon, Nov 13, 2017 at 12:56:31PM -0800, Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 12:10 PM, Andi Kleen wrote:
> >
> > You're right. It works for line information, but strangely not for
> > inlines. I assume it can be fixed.
>
> So I'm not 100% su
> Put another way: the CONFIG_DEBUG_INFO_SPLIT option is useless. Yes,
> it saves time and disk space, but does so at the expense of making all
> the debug information unavailable to basic tools.
You're right. It works for line information, but strangely not for
inlines. I assume it can be fixed.
> > It's the "CONFIG_DEBUG_INFO_SPLIT" thing that makes faddr2line unable
> > to see the inlining information,
> >
> > Using OPTIMIZE_INLINING is fine.
>
> Good to know that!
It works for me. Perhaps your binutils is too old? It was
added at some point. Can you try upgrading?
% ./linux/scripts/
Tariq Toukan writes:
>
> Congestion in this case is very clear.
> When monitored in perf top:
> 85.58% [kernel] [k] queued_spin_lock_slowpath
Please look at the callers. Spinlock profiles without callers
are usually useless because it's just blaming the messenger.
Most likely the PCP lists are t
> 64-bit x86_64:
> [0.509409] test_siphash: SipHash2-4 cycles: 4049181
> [0.510650] test_siphash: SipHash1-3 cycles: 2512884
> [0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920
> [0.512904] test_siphash:JenkinsHash cycles: 978267
I'm not sure what these numbers m
Eric Dumazet writes:
> On Thu, 2016-09-22 at 18:43 +0200, Vlastimil Babka wrote:
>> The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
>> with the number of fds passed. We had a customer report page allocation
>> failures of order-4 for this allocation. This is a costly o
"D. Herrendoerfer" writes:
>
> I may be missing something here - I'm pretty sure there I am, but is
> there any conceptual
>
> reason why this should not be done this way ?
What happens if someone floods the network with random mac addresses?
Sounds like an easy way to do a DoS attack against you
> +1, I tried to bring this up here [1] in the last spin. I think only very
> few changes would be needed, f.e. on eBPF side to add a queue setting
> helper function which is probably straight forward ~10loc patch; and with
> regards to actually picking it up after clsact egress, we'd need to adapt
> > So where is your policy for power saving? From past experience I can tell
> > you
>
> There is no policy for power saving yet. I will add it to my todo list.
Yes it's interesting to consider. The main goal here is to maximize CPU
idle residency? I wonder if that's that much different from t
> I wonder if this can be attacked from a different angle. What would be
> missing to add support for this in user space? The first possibility
> that came to my mind is to just multiplex those hints in the kernel.
"just" is the handwaving part here -- you're proposing a micro kernel
approach wher
> It seems strange to me to add such policies to the kernel.
> Addmittingly, documentation of some settings is non-existent and one needs
> various different tools to set this (sysctl, procfs, sysfs, ethtool, etc).
The problem is that different applications need different policies.
The only entit
Shanker Wang writes:
> This patch removes the check for CAP_NET_ADMIN in the initial namespace
> when opening /dev/open. Instead, CAP_NET_ADMIN is checked in the user
> namespace the net namespace was created so that /dev/ppp cat get opened
> in a unprivileged container.
Seems dangerous. From a
> > There are two ways to fix the warnings:
> >
> > 1. get rid of the thunks and call the C functions directly; or
>
> No. Not until gcc learns about per-function callibg conventions (so that it
> can
> be marked as not clobbering registers).
It does already for static functions in 5.x (with -fi
Tom Herbert writes:
> Also, we don't do anything special for alignment, unaligned
> accesses on x86 do not appear to be a performance issue.
This is not true on Atom CPUs.
Also on most CPUs there is still a larger penalty when crossing
cache lines.
> Verified correctness by testing arbitrary l
> >This would be be great. I've recently ran into some issues with
> >the overhead of the Android firewall setup.
> >
> >So basically you need 4 extra bytes in sk_buff. How about:
> >
> >- shrinking skb->priority to 2 byte
>
> That wouldn't work, see SO_PRIORITY and such (4 bytes) ...
But does an
Lorenzo Colitti writes:
> On Wed, Nov 25, 2015 at 5:32 AM, Matt Bennett
> wrote:
>> I'm emailing this list for feedback on the feasibility of increasing
>> skb->mark or adding a new field for marking. Perhaps this extension
>> could be done under a new CONFIG option.
>
> 64-bit marks (both skb->
> My specific CPU (i7-4790K @ 4.00GHz) unfortunately seems to have
> limited "Frontend" support. E.g.
>
> # perf record -g -a -e stalled-cycles-frontend
> Error:
> The stalled-cycles-frontend event is not supported.
>
> And AFAIK icache misses are part of "frontend".
Ignore stalled-cycles-fr
> There is a recent patch that may help here, see below, but maybe its
> just a matter of removing that :pp, as it ends with a /pp anyway, no
> need to state that twice :)
Yes the extra :pp was a regression in toplev. I fixed it now. Thanks.
-Andi
--
To unsubscribe from this list: send the line "
> My only problem left, is I want a perf measurement that pinpoint these
> kind of spots. The difference in L1-icache-load-misses were significant
> (1,278,276 vs 2,719,158). I tried to somehow perf record this with
> different perf events without being able to pinpoint the location (even
> thoug
> Is it possible to catch this automatically, like, by re-defining
> likely/unlikely to the raw form in specific file(s)?
Sure it would be possible to define a IN_VDSO symbol in all vdso
related files and then do that. Might be useful for other things
too. vdso has some very specific requirements.
Andrew Morton <[EMAIL PROTECTED]> writes:
>> -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
>
> This is a surprise. I expect that the -mm-only
> profile-likely-unlikely-macros.patch is the cause of this and mainline
> doesn't have this problem.
Shouldn't they only have overhead when the
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> It should be possible to use a modular jhash.ko. The things which you
> have identified as clients of the jhash library are usually loaded as modules.
For very small functions like this own modules are quite expensive. First
everything gets rounded
Rémi Denis-Courmont <[EMAIL PROTECTED]> writes:
> Le Friday 15 February 2008 18:30:11 Andi Kleen, vous avez écrit :
>> David Miller <[EMAIL PROTECTED]> writes:
>> > From: Rémi_Denis-Courmont <[EMAIL PROTECTED]>
>> > Date: Thu, 14 Feb 2008 18:53:34 +02
David Miller <[EMAIL PROTECTED]> writes:
> From: Rémi_Denis-Courmont <[EMAIL PROTECTED]>
> Date: Thu, 14 Feb 2008 18:53:34 +0200
>
>> Fixes a segmentation fault when trying to splice from a non-TCP socket.
>>
>> Signed-off-by: Rémi Denis-Courmont <[EMAIL PROTECTED]>
>
> Applied, thank you.
That'
Sven Wegener <[EMAIL PROTECTED]> writes:
> The default synchronization interval of 1000 milliseconds is too high for a
> heavily loaded director. Collecting the connection information from one second
> and then sending it out in a burst will overflow the socket buffer and lead to
> synchronization
Hi,
Since I updated a system here from 2.6.24rc8 (+ some unrelated patches)
to 2.6.24 openswan in tunnel mode is rather unhappy now. It works
initially for a few minutes, but then when it comes to renew a key (I think)
the connection always hangs. This means on 2.6.24-final the kernel
can now
On Thu, Feb 07, 2008 at 02:44:46PM -0500, Ross Vandegrift wrote:
> On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
> > That would be useful yes -- for different bandwidths.
>
> My initial test is end-to-end 1000Mbps, but I've got a few different
> packet rates.
On Wed, Feb 06, 2008 at 09:36:11AM -0800, Glenn Griffin wrote:
> > I didn't think a module could have multiple module_inits. Are you
> > sure that works?
>
> Indeed. That will fail whenever ipv6 is compiled as a module. It's
> been removed. It snuck in from the v4 implementation, where I'm stil
> I work at a hosting company and we see these kinds of issues in the
> real world fairly frequently. I would guess maybe a monthly basis.
> The servers where we have seen this are typically running RHEL 4 or 5
> kernels, so I can't really speak to how recent the kernel is in this
> specific term.
> +static __init int init_syncookies(void)
> +{
> + get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
> + return 0;
> +}
> +module_init(init_syncookies);
I didn't think a module could have multiple module_inits. Are you
sure that works?
-Andi
--
To unsubscribe from this list:
On Tue, Feb 05, 2008 at 11:39:11PM +0300, Evgeniy Polyakov wrote:
> On Tue, Feb 05, 2008 at 09:02:11PM +0100, Andi Kleen ([EMAIL PROTECTED])
> wrote:
> > On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
> > > > Syncookies are discouraged these day
> The problem is that any reasonably recent PC can generate enough
> forged SYN packets to overwhelm reasonable SYN queues on a much more
> powerful server.
Have you actually seen this with a recent kernel in the wild or are
you just talking theoretically?
Linux uses some heuristics to manage the
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
> > Syncookies are discouraged these days. They disable too many
> > valuable TCP features (window scaling, SACK) and even without them
> > the kernel is usually strong enough to defend against syn floods
> > and systems have much more
On Tue, Feb 05, 2008 at 04:03:01PM +, Alan Cox wrote:
> > Also your sub PC class appliances rarely run LISTEN servers anyways
> > that are open to the world.
>
> Really. The ones that first come to mind often have exposed ports
> including PDA devices and phones. (Ditto low end PC boxes - port
On Tue, Feb 05, 2008 at 03:42:13PM +, Alan Cox wrote:
> > Syncookies are discouraged these days. They disable too many
> > valuable TCP features (window scaling, SACK) and even without them
> > the kernel is usually strong enough to defend against syn floods
> > and systems have much more mem
On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote:
> Add IPv6 support to TCP SYN cookies. This is written and tested against
> 2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately
> linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against
> th
> Nothing that looks like a struct net_device. All the dumped leaked slab
> look the same until "45 20 05 d8" (the ascii 'E' on the 3rd line).
45 ... is often the start of an IP header (IPv4, 5*4=20 bytes length)
You could dump them to a file (e.g. using a sial script) and then
look at them with
Matti Aarnio <[EMAIL PROTECTED]> writes:
> .. the original reason was apparently that _ifconfig_ blew up
> when it saw protocols that it didn't understand on network
> interfaces. Possibly when there was no IP protocol on an
> interface.
It's not only ifconfig, a lot of programs use SIOCGIFCONF
Hallo,
While looking for something else in tcp_output.c I noticed that
MTU probing seems to be only done in tcp_write_xmit (when
packets come directly from process context), but not via the timer
driven timer retransmit path (tcp_retransmit_skb). Is that intentional?
It looks quite weird. I would
On Sun, Feb 03, 2008 at 09:57:10AM +1100, Herbert Xu wrote:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> Then change TBF to use skb_gso_segment? Be careful, the fact that
> >
> > That doesn't help because it wants to interleave packets
> > from different
> Turning TSO off at netdev registration time with a warning will be a
> cleaner IMO. Or alternatively introducing a kernel-config "I know what
You mean the qdisc should force TSO off on the underlying device?
> TSO is" option which is then used at netdev registration. From a
> usability perspec
On Fri, Feb 01, 2008 at 01:58:30PM -0800, Rick Jones wrote:
> >>Does this also imply that JumboFrames interacts badly with these qdiscs?
> >>Or IPoIB with its 65000ish byte MTU?
> >
> >
> >Correct. Of course it is always relative to the link speed. So if your
> >link is 10x faster and your packets
> The TSO defer logic is based on your congestion window and current
> window size. So the actual frame sizes hitting your NIC attached to
> your DSL probably aren't anywhere near 64KB, but probably more in line
> with whatever your window size is for DSL.
DSL windows can be quite large because a
On Fri, Feb 01, 2008 at 02:51:40PM +0200, Ivan Dichev wrote:
> Arnaldo Carvalho de Melo wrote:
> > Em Fri, Jan 25, 2008 at 02:21:08PM +0100, Andi Kleen escreveu:
> >
> >> "Ivan H. Dichev" <[EMAIL PROTECTED]> writes:
> >>
> >>>
> The problem with ethtool is that it's a non-obvious nerd knob. At
> the least the ethtool documentation should be updated to indicate that
> activating TSO effects tc accuracy.
TSO tends to be activated by default in the driver; very few people who use it
do even know that ethtool exist or wha
On Thu, Jan 31, 2008 at 09:33:44PM +0100, Jarek Poplawski wrote:
> Andi Kleen wrote, On 01/31/2008 08:34 PM:
>
> >> TSO by nature is bursty. But disabling TSO without the option of having
> >> it on or off to me seems to aggressive. If someone is using a qdisc
> >
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
If anything TC, not ethtool. Do you have an useful scenario where
GSO makes sense with TBF et.al.?
-Andi
--
To unsubscribe from this list: se
On Thu, Jan 31, 2008 at 03:42:54PM -0800, Waskiewicz Jr, Peter P wrote:
> > Well, it could be just that when using such qdiscs TSO would be
> > disabled, but the user could override this by using ethtool after
> > loading the qdiscs.
>
> I still disagree with this. The qdisc should not cause anyt
On Thu, Jan 31, 2008 at 11:14:34AM -0800, Rick Jones wrote:
> Sounds like the functionality needs to be in the DSL bridge :) (or the
> "router" in the same case) Particularly since it might be getting used
> by more than one host on the GbE switch.
Possible, but it is not usually in the real wor
> TSO by nature is bursty. But disabling TSO without the option of having
> it on or off to me seems to aggressive. If someone is using a qdisc
> that TSO is interfering with the effectiveness of the traffic shaping,
> then they should turn off TSO via ethtool on the target device. Some
The phi
On Thu, Jan 31, 2008 at 07:46:02PM +0100, Patrick McHardy wrote:
> Patrick McHardy wrote:
>> Andi Kleen wrote:
>>
>>> Can you please try with the above config?
>> I'll give it a try later.
>
>
> I took all options from that config that seemed possibly
&
> So, at what timescale do people using these qdiscs expect things to
> appear "smooth?" 64KB of data at GbE speeds is something just north of
> half a millisecond unless I've botched my units somewhere.
One typical use case for TBF is you talking to a DSL bridge that
is connected using a GBit
On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote:
> Andi Kleen wrote:
> >TSO interacts badly with many queueing disciplines because they rely on
> >reordering packets from different streams and the large TSO packets can
> >make this difficult. This patch disables
On Thu, Jan 31, 2008 at 07:21:20PM +0100, Patrick McHardy wrote:
> Andi Kleen wrote:
> >>Then change TBF to use skb_gso_segment? Be careful, the fact that
> >
> >That doesn't help because it wants to interleave packets
> >from different streams to get everything
> Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way to do
this is to just tell TCP to not do
On Thu, Jan 31, 2008 at 07:01:00PM +0100, Patrick McHardy wrote:
> Andi Kleen wrote:
> >>Fix the broken qdisc instead.
> >
> >What do you mean? I don't think the qdiscs are broken.
> >I cannot think of any way how e.g. TBF can do anything useful
> >with la
> Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way how e.g. TBF can do anything useful
with large TSO packets.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
On Thu, Jan 31, 2008 at 08:41:38AM -0800, Ben Greear wrote:
> I don't know exactly how the tcp_tw_recycle works, but it seems like it
> could be made to only
> take affect when all local ports are used up in TIME_WAIT.
TIME-WAIT does not actually use up local ports; it uses up remote ports
beca
> Works for me:
>
> qdisc tbf 8001: root rate 1000bit burst 10b/8 mpu 0b lat 720.0ms
> Sent 0 bytes 0 pkt (dropped 9, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
> Packets are dropped as expected.
I can still reproduce it on 64bit with http://halobates.de/config-qdisc
> -
> lilsol:~# tc qdisc add dev eth0 root tbf rate 1000 burst 10 limit 100
> lilsol:~# uname -a
> Linux lilsol 2.6.24 #1 PREEMPT Sun Jan 27 09:22:00 EST 2008 i686
Can you try it again with current git mainline?
> GNU/Linux
> lilsol:~# tc qdisc ls dev eth0
> qdisc tbf 8001: root rate 100
ns 99+% of all users
will still be able to use TSO just fine.
The status is only set up at socket creation so a shifted route
will not reenable TSO on a existing socket. I don't think that's a
problem though.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/net/sch_ge
On Thursday 31 January 2008 13:21:00 Andi Kleen wrote:
>
> I just managed to hang a 2.6.24 (+ some non network patches) kernel
> with the following (non sensical) command
Correction: the kernel was actually a git linus kernel with David's
recent merge included.
I found it&#x
I just managed to hang a 2.6.24 (+ some non network patches) kernel
with the following (non sensical) command
tc qdisc add dev eth0 root tbf rate 1000 burst 10 limit 100
No oops or anything just hangs. While I understand root can
do bad things just hanging like this seems a little extreme.
-A
Bruce Allen <[EMAIL PROTECTED]> writes:
>
> Important note: we ARE able to get full duplex wire speed (over 900
> Mb/s simulaneously in both directions) using UDP. The problems occur
> only with TCP connections.
Another issue with full duplex TCP not mentioned yet is that if TSO is used
the outp
> I believe the problem was that all of my ports were used up with
> TIME_WAIT sockets and so it couldn't create more. My test
> case was similar to this:
Ah that's simple to solve then :- use more IP addresses and bind
to them in RR in your user program.
Arguably the Linux TCP code should be
On Wednesday 30 January 2008 20:22, Ben Greear wrote:
> We use these features to enable creating very high numbers of short-lived
> TCP connections, primarily used as a test tool for other network
> devices.
Hopefully these other network devices don't do any NAT then
or don't otherwise violate th
On Wed, Jan 30, 2008 at 09:03:16AM -0800, Roland Dreier wrote:
> > On a 2GB Core2 system here I see a time cat /proc/net/tcp > /dev/null
> > constently dropping from 0.44s to 0.4-0.8s system time with this change.
>
> Seems like there must be a typo in either the before or after times
> you repo
s code for 2.6.26
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/Documentation/feature-removal-schedule.txt
===
--- linux.orig/Documentation/feature-removal-schedule.txt
+++ linux/Documentation/feature-removal-schedu
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 30. Januar 2008 09:01:10 schrieb Andi Kleen:
>>
>> gcc does not generate different code for return foo vs bar = foo; goto x;
>> x: return bar; So convert it all to direct returns for better readability.
>
&
/net/tcp.
Original idea for this patch from Marcus Meissner, but redone by me.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_ipv4.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
Index: linux/net/i
gcc does not generate different code for return foo vs bar = foo; goto x;
x: return bar; So convert it all to direct returns for better readability.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/net/ipv4/tcp_
"Ivan H. Dichev" <[EMAIL PROTECTED]> writes:
>
> What could happen if I put different Lan card in every slot?
> In ex. to-private -> 3com
> to-inet-> VIA
> to-dmz -> rtl8139
> And then to look which RX function is consuming the memory.
> (boomerang_rx, rtl8139_rx, ... etc)
The
> [Ram] I am assuming that this is with regards to msi-x interrupts. We
Yes.
And avoiding bouncing locks for device state between CPUs.
> have done away with handling tx completion in the interrupt handler, and
> are instead handling them in the context of the transmit. The slow path,
> straggl
Sreenivasa Honnur <[EMAIL PROTECTED]> writes:
> Multiqueue netwrok device support implementation.
> - Added a loadable parameter "multiq" to enable/disable multiqueue support,
> by default it is disabled.
> - skb->queue_mapping is not used for queue/fifo selection. FIFO iselection is
> based o
> It seems to have stopped when i stopped using ipsec and started using
> vpnc.
Kernel ipsec was active yes. However I normally don't see it although
it is often active, that was the first time I think
(except long ago)
> (but no firm info - this was sporadic - happened every few months
> or
My workstation running 2.6.24-rc8 just hung during shutdown with an endless
(or rather I didn't wait more than a few minutes) loop of
unregister_netdev: waiting for ppp-device to become free. Usage count = 1
ppp-device was an active PPPoE device.
No more information currently.
-Andi
--
To un
"Ilpo Järvinen" <[EMAIL PROTECTED]> writes:
>
> Besides, it not always that obvious that gcc is able to determine "the
> constant state", considering e.g., the complexity in the cases with
> tcp_rcv_synsent_state_process, tcp_close_state, tcp_done. In such cases
> uninlining should be done and gcc
> I think it should be in netdev_unregister_kobject(). But that would
> only get rid of one of the two calls to synchronize_rcu() in the
> unregister_netdev.
Would be already an improvement.
> The other synchronize_rcu() is for qdisc's and not sure if that one can
> be removed?
The standard w
Vince Fuller <[EMAIL PROTECTED]> writes:
> from Vince Fuller <[EMAIL PROTECTED]>
>
> This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
> (aka "class-E") address space as consistent with the Internet Draft
> draft-fuller-240space-00.txt.
Wouldn't it be wise to at least wait for
> Postponing freeing of the skb has major drawbacks. Some time ago I
Yes, the trick would be to make sure that it also does not tie up
too much memory. e.g. it would need some throttling at least.
Also the fast path of kmem_cache_free() is actually not that
much different from just putting someth
> It adds severe spikes in CPU utilization that are even moderate
> line rates begins to affect RTTs.
>
> Or do you think it's OK to process 500,000 SKBs while locked
> in a software interrupt.
You can always push it into a work queue. Even put it to
other cores if you want.
In fact this is al
David Miller <[EMAIL PROTECTED]> writes:
>
> The big problem is that recovery from even a single packet loss in a
> window makes us run kfree_skb() for a all the packets in a full
> window's worth of data when recovery completes.
Why exactly is it a problem to free them all at once? Are you worrie
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> I usually just compile a small program like
Just use scripts/decodecode and cat the Code line into that.
> particularly good way to do it, and the old "ksymoops" program used to do
> a pretty good job of this, but I'm used to that particular idiotic
On Mon, Jan 07, 2008 at 07:37:00PM -0800, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 8 Jan 2008 03:05:29 +0100
>
> > On Mon, Jan 07, 2008 at 05:54:58PM -0800, David Miller wrote:
> > > I explicitly left them out.
> > >
> >
> % awk ' { line++ } ; /^{/ { start = line } ; /^}/ { n++; r += line-start-2;
> } ; END { print r/n }' < include/net/tcp.h
> 9.48889
>
> The average function length is 9 lines.
Actually 8 -- the awk hack had a off by one. Still too long.
-Andi
--
To unsubscribe from this list: send the line "
On Mon, Jan 07, 2008 at 05:54:58PM -0800, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 08 Jan 2008 01:23:11 +0100
>
> > David Miller <[EMAIL PROTECTED]> writes:
> >
> > > Similarly I question just about any inline usage at all
1 - 100 of 579 matches
Mail list logo
