Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line

> 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

Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line

On Mon, Nov 13, 2017 at 12:56:31PM -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 12:10 PM, Andi Kleen <a...@linux.intel.com> wrote: > > > > You're right. It works for line information, but strangely not for > > inlines. I assume it can be fixed. > > S

Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line

> 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.

Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line

> > 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? %

Re: Page allocator bottleneck

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

Re: [PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables

> 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

Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)

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

Re: [RFC] bridge: MAC learning uevents

"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

Re: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue

> +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

Re: [RFC PATCH 00/30] Kernel NET policy

> > 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

Re: [RFC PATCH 00/30] Kernel NET policy

> 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

Re: [RFC PATCH 00/30] Kernel NET policy

> 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

Re: [PATCH] net:ppp: replace too strict capability restriction on opening /dev/ppp

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

Re: [PATCH 00/33] Compile-time stack metadata validation

> > 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

Re: [PATCH v2 net-next] net: Implement fast csum_partial for x86_64

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

Re: Increasing skb->mark size

> >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

Re: Increasing skb->mark size

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

Re: [MM PATCH V4.1 5/6] slub: support for bulk free with SLUB freelists

> 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

Re: [MM PATCH V4.1 5/6] slub: support for bulk free with SLUB freelists

> 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

Re: [MM PATCH V4.1 5/6] slub: support for bulk free with SLUB freelists

> 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 >

Re: [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/

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 up

Re: [RFC PATCH 0/8]: uninline uninline

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

Re: [RFC PATCH 0/8]: uninline uninline

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.

Re: [PATCH] Make sure sockets implement splice_read

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's also a stable

Re: [PATCH] Make sure sockets implement splice_read

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 +0200 Fixes a segmentation fault when trying to splice from

Re: [PATCH] ipvs: Make the synchronization interval controllable

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

openswan broken between 2.6.24rc8 and final

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

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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. If the young/old

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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.

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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 that.

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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 memory

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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 - portscan

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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 memory

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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

Re: [PATCH] Add IPv6 support to TCP SYN cookies

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 days. They disable too many valuable TCP

Re: [PATCH] Add IPv6 support to TCP SYN cookies

+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: send

Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?

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 to

Re: Slow OOM in netif_RX function

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

Re: [PATCH] Disable TSO for non standard qdiscs

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 streams to get everything fair and smooth. The only

No pmtu probing on retransmits?

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

Re: Slow OOM in netif_RX function

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: What could happen if I put different Lan card in every slot? In ex. to-private

Re: [PATCH] Disable TSO for non standard qdiscs

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

Re: [PATCH] Disable TSO for non standard qdiscs

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 10x bigger

Re: [PATCH] Disable TSO for non standard qdiscs

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 perspective

Re: e1000 full-duplex TCP performance well below wire speed

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 output

hard hang through qdisc

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.

[PATCH] Disable TSO for non standard qdiscs

+% 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_generic.h |1 + net/core

Re: hard hang through qdisc II

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's pretty easy to hang

Re: hard hang through 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 1000bit

Re: hard hang through qdisc

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 (all

Re: [PATCH] [1/1] Deprecate tcp_tw_{reuse,recycle}

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

Re: [PATCH] Disable TSO for non standard qdiscs

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] More

Re: [PATCH] Disable TSO for non standard qdiscs

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

Re: [PATCH] Disable TSO for non standard qdiscs

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 fair and smooth. The only good way

Re: [PATCH] Disable TSO for non standard qdiscs

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 TSO for sockets that send

Re: [PATCH] Disable TSO for non standard qdiscs

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

Re: [PATCH] Disable TSO for non standard qdiscs

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

Re: hard hang through qdisc

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 related (qdiscs, no hrtimers, no nohz, slab

Re: [PATCH] Disable TSO for non standard qdiscs

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 world.

Re: [PATCH] Disable TSO for non standard qdiscs

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 anything to

Re: [PATCH] Disable TSO for non standard qdiscs

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: send

Re: [PATCH] Disable TSO for non standard qdiscs

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 that TSO is interfering

Re: [PATCH] Disable TSO for non standard qdiscs

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 what

[PATCH] [1/2] Skip empty hash buckets faster in /proc/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/ipv4/tcp_ipv4.c

[PATCH] [2/2] Remove some unnecessary gotos in established_get_first()

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_ipv4.c

Re: [PATCH] [2/2] Remove some unnecessary gotos in established_get_first()

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. Now suppose somebody needs to change

[PATCH] [1/1] Deprecate tcp_tw_{reuse,recycle}

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-schedule.txt @@ -354,3

Re: [PATCH] [1/2] Skip empty hash buckets faster in /proc/net/tcp

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 report

Re: [PATCH] [1/1] Deprecate tcp_tw_{reuse,recycle}

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 the

Re: [PATCH] [1/1] Deprecate tcp_tw_{reuse,recycle}

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

Re: Slow OOM in netif_RX function

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 problem is

Re: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation

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 on IP-TOS

Re: [PATCH 2.6.25 1/1]S2io: Multiqueue network device support implementation

[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, straggling

2.6.24 regression: reference count leak in PPPoE

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

Re: 2.6.24 regression: reference count leak in PPPoE

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 so)

Re: [PATCH 1/8] [TCP]: Uninline tcp_set_state

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 is

Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system

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 way

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

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 it

Re: SACK scoreboard

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

Re: Top 10 kernel oopses for the week ending January 5th, 2008

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 way

Re: SACK scoreboard

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 worried

Re: SACK scoreboard

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

Re: [PATCH 3/4] [XFRM]: Kill some bloat

David Miller [EMAIL PROTECTED] writes: Similarly I question just about any inline usage at all in *.c files Don't forget the .h files. Especially a lot of stuff in tcp.h should be probably in some .c file and not be inline. -Andi -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 3/4] [XFRM]: Kill some bloat

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 in *.c files Don't forget the .h files. Especially

Re: [PATCH 3/4] [XFRM]: Kill some bloat II

% 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

Re: [PATCH 3/4] [XFRM]: Kill some bloat

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. Most of them are abstractions of common 2 or 3 instruction

Re: NAPI poll behavior in various Intel drivers

David Miller [EMAIL PROTECTED] writes: From: James Chapman [EMAIL PROTECTED] Date: Sat, 05 Jan 2008 00:18:31 + David Miller wrote: From: James Chapman [EMAIL PROTECTED] Date: Fri, 04 Jan 2008 20:10:30 + With the latest NAPI, this code has to change. But rather than remove

Re: Top 10 kernel oopses for the week ending January 5th, 2008

Arjan van de Ven [EMAIL PROTECTED] writes: Rank 4: remove_proc_entry Was also ranked 4th last week Only in tainted oopses Reported 3 times (12 total reports) More info: http://www.kerneloops.org/search.php?search=remove_proc_entry Likely a broken module_exit()

Re: Top 10 kernel oopses for the week ending January 5th, 2008

On Sat, Jan 05, 2008 at 07:31:29PM -0800, Arjan van de Ven wrote: Andi Kleen wrote: Arjan van de Ven [EMAIL PROTECTED] writes: Rank 4: remove_proc_entry Was also ranked 4th last week Only in tainted oopses Reported 3 times (12 total reports) More info: http

Re: [RFC] skge csum problems

Al Viro [EMAIL PROTECTED] writes: Checksum is fixed-endian and we want it that way; IOW, what we end up storing in skb-csum should be fixed-endian as well. AFAIK skb-csum is always native endian because it normally needs to be manipulated further even for RX. -Andi -- To unsubscribe from this

Re: Top 10 kernel oopses/warnings for the week of December 21st 2007

Arjan van de Ven [EMAIL PROTECTED] writes: Rank 8: __change_page_attr BUG at arch/x86/mm/pageattr_64.c:176 Reported 2 times Reported this week for 2.6.24-rc5; history goes back to 2.6.15 There is no BUG on this line on 2.6.24-rc5. Since there are many BUG_ONs in

Re: Top 10 kernel oopses/warnings for the week of December 21st 2007

in this case this is really all the version information available ;( it seems to be a patched kernel without patched EXTRAVERSION. But in the future if I have more specific information (eg it's only 1 kernel version) I'll mention it in more detail. It gets unwieldy if there's 500 reports for

Re: [PATCH RFC] [3/9] modpost: Declare the modpost error functions as printf like

On Mon, Dec 10, 2007 at 07:50:08PM +0100, Sam Ravnborg wrote: On Thu, Nov 22, 2007 at 03:43:08AM +0100, Andi Kleen wrote: This way gcc can warn for wrong format strings This loks good. Can I get i s-o-b then I will apply it. Sorry must have been left out by mistake. Signed-off-by: Andi

Re: [PATCH RFC] [5/9] modpost: Fix a buffer overflow in modpost

On Monday 10 December 2007 20:32, Sam Ravnborg wrote: On Thu, Nov 22, 2007 at 03:43:10AM +0100, Andi Kleen wrote: When passing an file name 1k the stack could be overflowed. Not really a security issue, but still better plugged. Looks good. A s-o-b line again please. Signed-off-by: Andi

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

I think it would be good if you could specify a default namespace per module, that could reduce the amount of necessary changes significantly. But also give less documentation. It's also not that difficult to mark the exports once. I've forward ported such patches over a few kernels and didn't

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Wednesday 28 November 2007 17:48:17 Adrian Bunk wrote: On Wed, Nov 28, 2007 at 12:06:45AM +0100, Andi Kleen wrote: On Tue, Nov 27, 2007 at 03:00:22PM -0800, Stephen Hemminger wrote: ... of a modular ipv6 is flawed. Modules that cannot be unloaded are still useful. Standard case

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

Perhaps you've got lots of patches were people are using internal APIs they shouldn't? Maybe the issue is who can tell since what is external and what is internal is not explicitly defined? Exactly. Or rather it is not defined on the module level. We got static of course, but I

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Tue, Nov 27, 2007 at 03:26:52PM +1100, Rusty Russell wrote: On Monday 26 November 2007 16:58:08 Roland Dreier wrote: I agree that we shouldn't make things too hard for out-of-tree modules, but I disagree with your first statement: there clearly is a large class of symbols that

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Tue, Nov 27, 2007 at 08:43:24AM -0700, Jonathan Corbet wrote: Rusty said: Well, introduce an EXPORT_SYMBOL_INTERNAL(). It's a lot less code. But you'd still need to show that people are having trouble knowing what APIs to use. Might the recent discussion on the exporting of

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

With my Enterprise hat on, I can see where Andi was coming from originally. For the record my original motivation was to fix the TCP exports everything for ipv6.ko case cleanly. I later realized that it would be useful for the ABI stability issues too, but it was really not my primary

  1   2   3   4   5   6   >