Welcome to linux-kernel

Welcome to linux-kernel

[Majordomo]

--

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 <Majordomo@vger.kernel.org> with the following
command in the body of your email message:

    unsubscribe linux-kernel

or from another account, besides linux-kernel@vger.kernel.org:

    unsubscribe linux-kernel linux-kernel@vger.kernel.org

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 <owner-linux-kernel@vger.kernel.org> .
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

Re: Welcome to linux-kernel

[pramod babu G]

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

Re: Welcome to linux-kernel

[Rongfeng Tang]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

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
				
　　　　　　　　


[-- Attachment #2: fox.gif --]
[-- Type: image/gif, Size: 9519 bytes --]