2002-11-07 10:16:07

by Majordomo

[permalink] [raw]
Subject: Welcome to linux-kernel

--

Welcome to the linux-kernel mailing list!

Please save this message for future reference. Thank you.

If you ever want to remove yourself from this mailing list,
you can send mail to <[email protected]> with the following
command in the body of your email message:

unsubscribe linux-kernel

or from another account, besides [email protected]:

unsubscribe linux-kernel [email protected]

If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <[email protected]> .
This is the general rule for most mailing lists when you need
to contact a human.

Here's the general information for the list you've subscribed to,
in case you don't already have it:

This is the Linux kernel development discussion and bug reporting
mailing list. Volume is VERY high, 200-300 messages per day!
FAQ: http://www.tux.org/lkml/

Archives:
http://marc.theaimsgroup.com/?l=linux-kernel (Since -97)
http://groups.google.com/groups?group=mlist.linux.kernel (past year)
http://www.cs.helsinki.fi/linux/linux-kernel/ (Since -97)
http://www.lib.uaa.alaska.edu/linux-kernel/ (Since -00)
http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html (Since -95)

Ancient history:
http://www.linux.org.uk/Old-LK/Old-linux-kernel


2003-11-18 08:52:22

by pramod babu G

[permalink] [raw]
Subject: Re: Welcome to linux-kernel

hi ,
what is the routing look up speed in linux kernel. I am using linux
Router with zebra in that. My routing table size is 100000. How can i
measue the lookup speed. Is there any tool for that ???
bye


2004-04-27 08:08:26

by Rongfeng Tang

[permalink] [raw]
Subject: Re: Welcome to linux-kernel

Hi all,

I'm encountering a deadlock problem within kernel(2.4.19smp):

A lot of data writen into a network file system and the physical memory is almost exhausted, so that the kswapd calls the kswapd_balance -> try_to_free_pages->...->shrink_cache try to free a dirty page(just name it PageA) of the file system. the file system's writepage locks the page and sends the data to a dedicated process (named ProcB)of this file system in the same node which just send the data to remote server. ProcB communicates with server by TCP/IP. when the TCP/IP layer try to alloc a free page for transmission, it also arouse the kernel to free some dirty pages, what's a pity, the PageA has been selected. Since it's locked now , the shrink_cache just calls on wait_on_page, thus a big deadlock is generated.
Is it a bug? if not, please give me some advice on how to just out of this cycle.


Thanks

Rongfeng

????????????????


Attachments:
fox.gif (9.30 kB)