Re: Processing time spent in IRQ handling and what to do about it
On Tuesday 18 December 2007, Oded Arbel wrote: I can see that a lot of time is spent in the hard-IRQ region - sometimes more then all other regions together. Lets look for more hints... - Anything interesting in the logs (during boot and after) ? - Lets plug out all the hardware you can: network , USB, disks... - rmmod all the modules you can. - Boot with a different kernel version. - Nothing yet? Lets play with the BIOS... What stops the IRQs? How far will you go to catch an IRQ? # = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: 64-bit linux and 32-bit applications
On Dec 19, 2007 9:32 AM, Moshe Gorohovsky [EMAIL PROTECTED] wrote: What is the prevailing opinion about installing and running 32-bit applications and shared libraries on 64-bit Linux operating systems? It's a perfectly okay thing to do. Naturally it's a waste of memory (cause you end up loading similar sets of libraries twice), but it's not a sin. Do Red Hat based 64-bit operating systems support 32-bit applications and shared libraries, but Debian based 64-bit operating systems do not? They both do. The 32-bit support is a kernel thing. IIRC, the userspace facilities are a bit different: RedHat stores the 32-bit programs in the same filesystem hierarchy as the 64-bit ones (/usr/lib vs. /usr/lib64) whereas Debian shelves 32-bit binaries away in some chroot. Also, at least as of two years ago, RPM supported installing multiple architecture versions of a package whereas APT/dpkg did not (but 64-bit Debian maintains the 32-bit stuff in a chroot so I guess it maintains separate dpkg databases for it).
Re: Processing time spent in IRQ handling and what to do about it
Can you send an output of cat /proc/interrupts ? Is there any device sharing the IRQ line with the network interface? Bnx2 has NAPI support. The recent changes you saw recently are not related, they are improvements to the NAPI machanism (to support multiple device queues, not specific to bnx2) Aviv Greenberg On 12/19/07, Dotan Shavit [EMAIL PROTECTED] wrote: On Tuesday 18 December 2007, Oded Arbel wrote: I can see that a lot of time is spent in the hard-IRQ region - sometimes more then all other regions together. Lets look for more hints... - Anything interesting in the logs (during boot and after) ? - Lets plug out all the hardware you can: network , USB, disks... - rmmod all the modules you can. - Boot with a different kernel version. - Nothing yet? Lets play with the BIOS... What stops the IRQs? How far will you go to catch an IRQ? # = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Perl 5.10 has been released
Hi, Not only was yesterday the 20th birthday of Perl and it was also the release date of Perl 5.10 the latest version of Perl. There are many new features in the language such as * switch statement * say * state to create static ... err, I mean state variables * defined-or // * Smart Match operator ~~ * Regular expressions - Recursive patterns - Named Capture Buffers - Possessive Quantifiers * Lexical my $_ * Stacked filetest operators you can of course read the details in http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perl5100delta.pod but I am also going to give a talk about it on the upcoming Perl Workshop on 31 December. http://act.perl.org.il/ilpw2007/ regards Gabor -- Gabor Szabo http://www.szabgab.com/ Perl Training in Israel http://www.pti.co.il/ Profile: http://www.linkedin.com/profile?viewProfile=key=82476 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: 64-bit linux and 32-bit applications
Sorry, reply to list doesn't work with linux-il for some reason (at least with sylpheed claws) re-posting to the list ... On Wed, 19 Dec 2007 10:31:42 +0200 Ilya Konstantinov [EMAIL PROTECTED] wrote: On Dec 19, 2007 9:32 AM, Moshe Gorohovsky [EMAIL PROTECTED] wrote: What is the prevailing opinion about installing and running 32-bit applications and shared libraries on 64-bit Linux operating systems? It's a perfectly okay thing to do. Naturally it's a waste of memory (cause you end up loading similar sets of libraries twice), but it's not a sin. Do Red Hat based 64-bit operating systems support 32-bit applications and shared libraries, but Debian based 64-bit operating systems do not? They both do. The 32-bit support is a kernel thing. IIRC, the userspace facilities are a bit different: RedHat stores the 32-bit programs in the same filesystem hierarchy as the 64-bit ones (/usr/lib vs. /usr/lib64) whereas Debian shelves 32-bit binaries away in some chroot. Also, at least as of two years ago, RPM supported installing multiple architecture versions of a package whereas APT/dpkg did not (but 64-bit Debian maintains the 32-bit stuff in a chroot so I guess it maintains separate dpkg databases for it). I don't know exactly how things are run but on by amd64 debian system I have under / the directories drwxr-xr-x 15 root root 12288 2007-12-19 09:34 lib lrwxrwxrwx 1 root root20 2007-10-12 01:01 lib32 - /emul/ia32-linux/lib lrwxrwxrwx 1 root root 4 2007-10-12 00:32 lib64 - /lib I don't anything special to run the 32 bit stuff though = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Processing time spent in IRQ handling and what to do about it
Hi, You cannot turn it on/off. The driver may support this optional API or not. If it supports it, it's the driver sole decision when it's better to use polling/interrupt-per-packet according it its hardware specifics. I doubt whether this is exactly so for all NICS, as one might understand from your answer. For example, with e1000 NICs, you can select to build the driver with or without polling support. See, while configuring the kernel: Device Drivers-Network Device Support-Ethernet 1000 Mbit - Intel (R) PRO/1000 Gigabit Ethernet Support-Use RX polling (NAPI). selecting it sets the CONFIG_E1000_NAPI to y. By default, in newer kernels, for e1000, it comes with support for NAPI by default, but you can also build it without this support. And if you will look at the code of the driver, you will find in e1000_main.c module the following: #ifdef CONFIG_E1000_NAPI netdev-poll = e1000_clean; netdev-weight = 64; #endif Which means that , when building without CONFIG_E1000_NAPI set, you will not have the poll method and therefore no polling/NAPI. You have also the ability to choose NAPI for other nics; for example, Tulip; see Device Drivers-Network Device Support-Ethernet 10 or 100 Mbit - Tulip family network device support-Use NAPI RX polling. It could be that on other NICs you cannot turn it on/off. Broadcom was the first to release the tg3 driver with support for NAPI for Linux. So they have probably a lot of experience with it, and it could be that there NAPI support is built in and you cannot avoid it. BTW, with Open Solaris, this is exactly the situation: the NAPI support is in the core automatically; the driver start as interrupt driver, and changes to polling when there is a high load of interrupts.The drivers need not be built with any NAPI special support. The driver binary is the same when working with/without NAPI.There is a way, however, to configure kernel-wide NAPI parameters. Regards, Rami Rosen On Dec 18, 2007 10:14 PM, Oron Peled [EMAIL PROTECTED] wrote: On Tuesday, 18 בDecember 2007, Yedidyah Bar-David wrote: I am not an expert on this, but what you want might be NAPI - a new network driver infrastructure designed to solve just that. Google a bit - I do not know exactly when it entered 2.6 (and you did not state your kernel version) and which drivers use it already. 1. NAPI was new at kernel 2.3.x when it was developed towards 2.4 2. It gives the *driver* the option to toggle between interrupt driven and polling mode at runtime. E.g: - A GB ethernet at full speed may better poll the hardware every once in a while. - The same card is better off using interrupt driven mode if the trafic is low. 3. You cannot turn it on/off. The driver may support this optional API or not. If it supports it, it's the driver sole decision when it's better to use polling/interrupt-per-packet according it its hardware specifics. 4. I don't think a single fast ethernet card can severely affect your hardware interrupt load. So either: - You have a GB (or maybe 2GB?) ethernet with high load. - You have several fast-ethernet cards working at full speed. 5. A far better suspect would be the disk controller (e.g: working without DMA etc.) 6. Why guess? watch -n10 -d cat /proc/interrupts And calculate how many interrupts per-sec occured for various devices. That would give you a rough idea who are the possible suspects. -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 Linux lasts longer! -- Kim J. Brand [EMAIL PROTECTED] To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: 64-bit linux and 32-bit applications
On Dec 19, 2007 4:33 PM, Moshe Gorohovsky [EMAIL PROTECTED] wrote: I want to install 32-bit vlc, mplayer and xine on 64-bit CentOS system. Will I need to install 32-bit versions of all dependencies, 32-bit libxine, libavcodec, etc.? Yes. yum should do it for you, assuming it has the proper sources available. Will these 32-bit libraries work if I already installed 64-bit libavcodec? Nope, the 64-bit libavcodec won't help a single bit.
Re: 64-bit linux and 32-bit applications
Hi list, Thanks for your replies. I want to install 32-bit vlc, mplayer and xine on 64-bit CentOS system. Will I need to install 32-bit versions of all dependencies, 32-bit libxine, libavcodec, etc.? Will these 32-bit libraries work if I already installed 64-bit libavcodec? Ilya Konstantinov wrote: On Dec 19, 2007 9:32 AM, Moshe Gorohovsky [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: What is the prevailing opinion about installing and running 32-bit applications and shared libraries on 64-bit Linux operating systems? It's a perfectly okay thing to do. Naturally it's a waste of memory (cause you end up loading similar sets of libraries twice), but it's not a sin. Do Red Hat based 64-bit operating systems support 32-bit applications and shared libraries, but Debian based 64-bit operating systems do not? They both do. The 32-bit support is a kernel thing. IIRC, the userspace facilities are a bit different: RedHat stores the 32-bit programs in the same filesystem hierarchy as the 64-bit ones (/usr/lib vs. /usr/lib64) whereas Debian shelves 32-bit binaries away in some chroot. Also, at least as of two years ago, RPM supported installing multiple architecture versions of a package whereas APT/dpkg did not (but 64-bit Debian maintains the 32-bit stuff in a chroot so I guess it maintains separate dpkg databases for it). -- Moshe Gorohovsky A6 CC A7 E1 C2 BD 8C 1B 30 8E A4 C3 4C 09 88 47 Tk Open Systems Ltd. --- - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
