To set some processes and Network softIRQ group to highest priority to make more stable performance
Dear experts, In my test bed, I hope to set some processes and related network softirqs to have highest priority than some other processes which can be delayed or can be executed in cpu idle condition. These critical processes that needs to have high priority are more cpu-time-slice-sensitive, and if any of threads of these process are delayed, then the total performance will be poor. I have googled a lot to find material on PRIORITY setting , however I do not know which are correct or accurate, or latest. I am eager to have insight on linux-kernel-pirority setting , or help me to learn some latest and professional material on Priority setting. Any one can help me? hope some suggestion.. Thanks a lot. Yanfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
To set some processes and Network softIRQ group to highest priority to make more stable performance
Dear experts, In my test bed, I hope to set some processes and related network softirqs to have highest priority than some other processes which can be delayed or can be executed in cpu idle condition. These critical processes that needs to have high priority are more cpu-time-slice-sensitive, and if any of threads of these process are delayed, then the total performance will be poor. I have googled a lot to find material on PRIORITY setting , however I do not know which are correct or accurate, or latest. I am eager to have insight on linux-kernel-pirority setting , or help me to learn some latest and professional material on Priority setting. Any one can help me? hope some suggestion.. Thanks a lot. Yanfei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Doubt on Implict BUGs caused LRO] doubt about lro status in v3.12 of torvalds/linux.git
Hi Eric, Thanks for quick reply. :-) Also, I am confused that in v3.12 why inet_lro.c file is not found in /net/ipv4/ directory, while Makefile has "obj-$(CONFIG_INET_LRO) += inet_lro.o" and LRO heads file exsits. If I am wrong, pls correct me, :-) See the steps 3 for details,(I have repeated it for several times) 3. cd net/ipv4, [backyes@f14 ipv4]$ cat Makefile | grep lro obj-$(CONFIG_INET_LRO) += inet_lro.o [backyes@f14 ipv4]$ ls inet_* inet_connection_sock.c inet_diag.c inet_fragment.c inet_hashtables.c inet_timewait_sock.c --- Best regards Yanfei Wang On Sat, Nov 23, 2013 at 12:32 AM, Eric Dumazet wrote: > On Fri, 2013-11-22 at 23:00 +0800, Yanfei Wang wrote: >> Hi, >> >> Compared to the earlier kernel version, I found that Large receive >> offload(LRO) is obsolete in latest kernel, and that is verified from >> other materials about Generic receive offload(GRO). >> >> However, I also found some LRO header files and lro-related >> functions referred by some drivers, and the lro-related function >> definition is already removed at the same time! >> >> TEST steps: >> 1. my git local db config as follow, url = >> http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> 2. git checkout v3.12 -b 3.12 >> 3. cd net/ipv4, >> [backyes@f14 ipv4]$ cat Makefile | grep lro >> obj-$(CONFIG_INET_LRO) += inet_lro.o >> [backyes@f14 ipv4]$ ls inet_* >> inet_connection_sock.c inet_diag.c inet_fragment.c >> inet_hashtables.c inet_timewait_sock.c >> [backyes@f14 ipv4]$ >> Here, Makefile has inet_lro.o config, while the inet_lro.c is removed. >> 4. lro functions referred by some drivers, as follow, >> [backyes@f14 linux]$ grep "inet_lro" * -r >> drivers/net/ethernet/pasemi/pasemi_mac.c:#include >> drivers/net/ethernet/pasemi/pasemi_mac_ethtool.c:#include >> drivers/infiniband/hw/nes/nes_hw.c:#include >> drivers/infiniband/hw/nes/nes_hw.h:#include >> include/linux/inet_lro.h: * linux/include/linux/inet_lro.h >> net/ipv4/Makefile:obj-$(CONFIG_INET_LRO) += inet_lro.o >> >> so, I understand that the removal of LRO is not clean, which will >> cause compiler error for some kernel config. >> > > I think you are slightly confused. > > LRO is not yet removed. > > Feel free to contribute ;) > > As long as at least one driver still uses LRO, we can not remove LRO. > > Converting a driver means testing the new driver, and owning the > hardware. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Doubt on Implict BUGs caused LRO] doubt about lro status in v3.12 of torvalds/linux.git
Hi, Compared to the earlier kernel version, I found that Large receive offload(LRO) is obsolete in latest kernel, and that is verified from other materials about Generic receive offload(GRO). However, I also found some LRO header files and lro-related functions referred by some drivers, and the lro-related function definition is already removed at the same time! TEST steps: 1. my git local db config as follow, url = http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. git checkout v3.12 -b 3.12 3. cd net/ipv4, [backyes@f14 ipv4]$ cat Makefile | grep lro obj-$(CONFIG_INET_LRO) += inet_lro.o [backyes@f14 ipv4]$ ls inet_* inet_connection_sock.c inet_diag.c inet_fragment.c inet_hashtables.c inet_timewait_sock.c [backyes@f14 ipv4]$ Here, Makefile has inet_lro.o config, while the inet_lro.c is removed. 4. lro functions referred by some drivers, as follow, [backyes@f14 linux]$ grep "inet_lro" * -r drivers/net/ethernet/pasemi/pasemi_mac.c:#include drivers/net/ethernet/pasemi/pasemi_mac_ethtool.c:#include drivers/infiniband/hw/nes/nes_hw.c:#include drivers/infiniband/hw/nes/nes_hw.h:#include include/linux/inet_lro.h: * linux/include/linux/inet_lro.h net/ipv4/Makefile:obj-$(CONFIG_INET_LRO) += inet_lro.o so, I understand that the removal of LRO is not clean, which will cause compiler error for some kernel config. -- Best Regard! Yanfei Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Doubt on Implict BUGs caused LRO] doubt about lro status in v3.12 of torvalds/linux.git
Hi, Compared to the earlier kernel version, I found that Large receive offload(LRO) is obsolete in latest kernel, and that is verified from other materials about Generic receive offload(GRO). However, I also found some LRO header files and lro-related functions referred by some drivers, and the lro-related function definition is already removed at the same time! TEST steps: 1. my git local db config as follow, url = http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. git checkout v3.12 -b 3.12 3. cd net/ipv4, [backyes@f14 ipv4]$ cat Makefile | grep lro obj-$(CONFIG_INET_LRO) += inet_lro.o [backyes@f14 ipv4]$ ls inet_* inet_connection_sock.c inet_diag.c inet_fragment.c inet_hashtables.c inet_timewait_sock.c [backyes@f14 ipv4]$ Here, Makefile has inet_lro.o config, while the inet_lro.c is removed. 4. lro functions referred by some drivers, as follow, [backyes@f14 linux]$ grep inet_lro * -r drivers/net/ethernet/pasemi/pasemi_mac.c:#include linux/inet_lro.h drivers/net/ethernet/pasemi/pasemi_mac_ethtool.c:#include linux/inet_lro.h drivers/infiniband/hw/nes/nes_hw.c:#include linux/inet_lro.h drivers/infiniband/hw/nes/nes_hw.h:#include linux/inet_lro.h include/linux/inet_lro.h: * linux/include/linux/inet_lro.h net/ipv4/Makefile:obj-$(CONFIG_INET_LRO) += inet_lro.o so, I understand that the removal of LRO is not clean, which will cause compiler error for some kernel config. -- Best Regard! Yanfei Wang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Doubt on Implict BUGs caused LRO] doubt about lro status in v3.12 of torvalds/linux.git
Hi Eric, Thanks for quick reply. :-) Also, I am confused that in v3.12 why inet_lro.c file is not found in /net/ipv4/ directory, while Makefile has obj-$(CONFIG_INET_LRO) += inet_lro.o and LRO heads file exsits. If I am wrong, pls correct me, :-) See the steps 3 for details,(I have repeated it for several times) 3. cd net/ipv4, [backyes@f14 ipv4]$ cat Makefile | grep lro obj-$(CONFIG_INET_LRO) += inet_lro.o [backyes@f14 ipv4]$ ls inet_* inet_connection_sock.c inet_diag.c inet_fragment.c inet_hashtables.c inet_timewait_sock.c --- Best regards Yanfei Wang On Sat, Nov 23, 2013 at 12:32 AM, Eric Dumazet eric.duma...@gmail.com wrote: On Fri, 2013-11-22 at 23:00 +0800, Yanfei Wang wrote: Hi, Compared to the earlier kernel version, I found that Large receive offload(LRO) is obsolete in latest kernel, and that is verified from other materials about Generic receive offload(GRO). However, I also found some LRO header files and lro-related functions referred by some drivers, and the lro-related function definition is already removed at the same time! TEST steps: 1. my git local db config as follow, url = http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. git checkout v3.12 -b 3.12 3. cd net/ipv4, [backyes@f14 ipv4]$ cat Makefile | grep lro obj-$(CONFIG_INET_LRO) += inet_lro.o [backyes@f14 ipv4]$ ls inet_* inet_connection_sock.c inet_diag.c inet_fragment.c inet_hashtables.c inet_timewait_sock.c [backyes@f14 ipv4]$ Here, Makefile has inet_lro.o config, while the inet_lro.c is removed. 4. lro functions referred by some drivers, as follow, [backyes@f14 linux]$ grep inet_lro * -r drivers/net/ethernet/pasemi/pasemi_mac.c:#include linux/inet_lro.h drivers/net/ethernet/pasemi/pasemi_mac_ethtool.c:#include linux/inet_lro.h drivers/infiniband/hw/nes/nes_hw.c:#include linux/inet_lro.h drivers/infiniband/hw/nes/nes_hw.h:#include linux/inet_lro.h include/linux/inet_lro.h: * linux/include/linux/inet_lro.h net/ipv4/Makefile:obj-$(CONFIG_INET_LRO) += inet_lro.o so, I understand that the removal of LRO is not clean, which will cause compiler error for some kernel config. I think you are slightly confused. LRO is not yet removed. Feel free to contribute ;) As long as at least one driver still uses LRO, we can not remove LRO. Converting a driver means testing the new driver, and owning the hardware. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How are cpu physical id & processor determined in /proc/cpuinfo ?
We found that, the sequence of processor and physical id are not same with different platform. Conf 1: 6cores processor *2 with numa-enabled. kernel 3.1.0 Ceontos 6.3 Conf 2: 6cores processor *2 with numa-enabled. kernel 3.1.0 Ceontos 6.3 Conf 1 and Conf2 own same OS, kernel, and CPU, the sequences of physical id from "cat /proc/cpuinfo" is not same. Conf1 has sequence with "cat /proc/cpuinfo |grep "physical id"" physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 ... Conf2 has following sequence instead: physical id:0 physical id:0 physical id:0 physical id:0 physical id:0 physical id:0 physical id:1 physical id:1 physical id:1 physical id:1 physical id:1 physical id:1 different cpu physical id sequence can probably causes severe numa-cross memory access for our program whose memory allocation depends directly on the logical cpu id, rather than carefully get numa node information with portable numa-API. Any one can clarify our trouble, thanks a lot. BR. Yanfei Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How are cpu physical id processor determined in /proc/cpuinfo ?
We found that, the sequence of processor and physical id are not same with different platform. Conf 1: 6cores processor *2 with numa-enabled. kernel 3.1.0 Ceontos 6.3 Conf 2: 6cores processor *2 with numa-enabled. kernel 3.1.0 Ceontos 6.3 Conf 1 and Conf2 own same OS, kernel, and CPU, the sequences of physical id from cat /proc/cpuinfo is not same. Conf1 has sequence with cat /proc/cpuinfo |grep physical id physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 physical id:0 physical id:1 ... Conf2 has following sequence instead: physical id:0 physical id:0 physical id:0 physical id:0 physical id:0 physical id:0 physical id:1 physical id:1 physical id:1 physical id:1 physical id:1 physical id:1 different cpu physical id sequence can probably causes severe numa-cross memory access for our program whose memory allocation depends directly on the logical cpu id, rather than carefully get numa node information with portable numa-API. Any one can clarify our trouble, thanks a lot. BR. Yanfei Wang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
