RE: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8,v2.6.21.7, v2.6.20.20
> De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar > Envoyé : 26 septembre 2007 07:14 > > By popular demand, here is release -v22 of the CFS scheduler. > It is a full backport of the latest & greatest > sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and > v2.6.20.20. The patches can be downloaded from the usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > This is the first time the development version of the > scheduler has been fed back into the stable backport series, > so there's many changes since > v20.5: > > 15 files changed, 1103 insertions(+), 840 deletions(-) > > Even if CFS v20.5 worked well for you, please try this > release too, with a good focus on interactivity testing - > because, unless some major showstopper is found, this > codebase is intended for a v2.6.24 upstream merge. > > ( Even a quick, subjective report of: "checked this patch, it didnt > crash and it feels like v20.5" or "laggier than v20.5" or "feels > better than v20.5" is useful to us and enables us to judge > the general > direction of interactivity. ) > > The changes in v22 consist of lots of mostly small > enhancements, speedups, interactivity improvements, debug > enhancements and tidy-ups - many of which can be > user-visible. (These enhancements have been contributed by > many people - see the changelog below and the git tree for > detailed credits.) > Better late than never... Hi Ingo & cie., I tested CFS v22 on a 2.6.20.10 and it is working like a charm. I used to have a few lags once in a while with v20.5 on a 2.6.20.6 kernel but they simply vanished with the v22 (although I'm currenctly mostly testing on etch with xorg 7.1 instead of sarge with xfree 4.3 so this might also have an effect...) It seems stable enough to put it in operation by next week on all our workstations. This is great work, thx to all CFS contributors. - vin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8,v2.6.21.7, v2.6.20.20
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar Envoyé : 26 septembre 2007 07:14 By popular demand, here is release -v22 of the CFS scheduler. It is a full backport of the latest greatest sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ This is the first time the development version of the scheduler has been fed back into the stable backport series, so there's many changes since v20.5: 15 files changed, 1103 insertions(+), 840 deletions(-) Even if CFS v20.5 worked well for you, please try this release too, with a good focus on interactivity testing - because, unless some major showstopper is found, this codebase is intended for a v2.6.24 upstream merge. ( Even a quick, subjective report of: checked this patch, it didnt crash and it feels like v20.5 or laggier than v20.5 or feels better than v20.5 is useful to us and enables us to judge the general direction of interactivity. ) The changes in v22 consist of lots of mostly small enhancements, speedups, interactivity improvements, debug enhancements and tidy-ups - many of which can be user-visible. (These enhancements have been contributed by many people - see the changelog below and the git tree for detailed credits.) Better late than never... Hi Ingo cie., I tested CFS v22 on a 2.6.20.10 and it is working like a charm. I used to have a few lags once in a while with v20.5 on a 2.6.20.6 kernel but they simply vanished with the v22 (although I'm currenctly mostly testing on etch with xorg 7.1 instead of sarge with xfree 4.3 so this might also have an effect...) It seems stable enough to put it in operation by next week on all our workstations. This is great work, thx to all CFS contributors. - vin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
El Sun, 30 Sep 2007 17:26:22 +0200 Ingo Molnar <[EMAIL PROTECTED]> escribió: > > > hm. There are no similar reports so far. Could you try to run the wine > program from a VGA text console (first do 'xhost +' in an xterm under X > and then 'export DISPLAY=:0' in the text console) and see whether > anything gets output to that console? Also enable nmi_watchdog=2 - which > could print a backtrace of the point of the hard lockup. Ignore the last mail there was no need to use pictures this no an oops on boot ;) This is the back trace Oct 2 17:37:13 localhost kernel: [ 886.216868] BUG: unable to handle kernel NULL pointer dereference at virtual address 012c Oct 2 17:37:13 localhost kernel: [ 886.216874] printing eip: Oct 2 17:37:13 localhost kernel: [ 886.216876] f9374d0c Oct 2 17:37:13 localhost kernel: [ 886.216877] *pde = Oct 2 17:37:13 localhost kernel: [ 886.216880] Oops: 0002 [#1] Oct 2 17:37:13 localhost kernel: [ 886.216881] PREEMPT SMP Oct 2 17:37:13 localhost kernel: [ 886.216884] Modules linked in: nls_cp850 isofs udf nls_utf8 ntfs binfmt_misc rfcomm l2cap bluetooth ipt_ULOG x_tables jfs ipv6 dm_crypt af_packet kvm_amd kvm fuse w83627ehf hwmon_vid i2c_dev lp snd_mpu401 snd_mpu401_uart snd_hda_intel snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer nvidia(P) snd_seq_device usbhid i2c_ali15x3 i2c_ali1535 8250_pnp usblp ff_memless uli526x snd i2c_core 8250 serial_core button ali_agp parport_pc parport k8temp hwmon pcspkr evdev rtc snd_page_alloc rt2500 soundcore sg floppy sr_mod raid10 cdrom sd_mod ehci_hcd ohci_hcd ata_generic usbcore raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan unix dm_mod Oct 2 17:37:13 localhost kernel: [ 886.216933] CPU:0 Oct 2 17:37:13 localhost kernel: [ 886.216934] EIP:0060:[] Tainted: PVLI Oct 2 17:37:13 localhost kernel: [ 886.216935] EFLAGS: 00010246 (2.6.23-rc9-cfs-v22-dirty #82) Oct 2 17:37:13 localhost kernel: [ 886.217129] EIP is at os_set_mlock_capability+0xc/0x30 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217131] eax: ebx: ecx: 0050 edx: 0202 Oct 2 17:37:13 localhost kernel: [ 886.217134] esi: f74c3000 edi: f749cc00 ebp: df4b3ff0 esp: d319bed4 Oct 2 17:37:13 localhost kernel: [ 886.217136] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Oct 2 17:37:13 localhost kernel: [ 886.217139] Process spirographx (pid: 5512, ti=d319b000 task=c45da540 task.ti=d319b000) Oct 2 17:37:13 localhost kernel: [ 886.217141] Stack: f909cd35 f909ed92 f9655740 e1d42c00 f6ca5bc0 f90a0c26 df4b2000 005b Oct 2 17:37:13 localhost kernel: [ 886.217146]000c f909da32 f9655740 e1d42c00 005b f6ca5bc0 f6ca5bc0 005b Oct 2 17:37:13 localhost kernel: [ 886.217151]f9655740 f9370e98 df4b2000 f9655740 e1d42c00 005b f6ca5bc0 Oct 2 17:37:13 localhost kernel: [ 886.217157] Call Trace: Oct 2 17:37:13 localhost kernel: [ 886.217164] [] _nv002553rm+0x5/0x10 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217259] [] rm_write_watch_init+0x3b/0x54 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217365] [] _nv002642rm+0x416/0x5e9 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217469] [] rm_ioctl+0x3e/0x6d [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217578] [] nv_kern_ioctl+0xf8/0x3c0 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217732] [] nv_kern_unlocked_ioctl+0x18/0x20 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217866] [] nv_kern_unlocked_ioctl+0x0/0x20 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217989] [do_ioctl+43/144] do_ioctl+0x2b/0x90 Oct 2 17:37:13 localhost kernel: [ 886.217994] [remove_vma+57/80] remove_vma+0x39/0x50 Oct 2 17:37:13 localhost kernel: [ 886.218010] [vfs_ioctl+92/656] vfs_ioctl+0x5c/0x290 Oct 2 17:37:13 localhost kernel: [ 886.218022] [sys_ioctl+114/144] sys_ioctl+0x72/0x90 Oct 2 17:37:13 localhost kernel: [ 886.218032] [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 Oct 2 17:37:13 localhost kernel: [ 886.218060] === Oct 2 17:37:13 localhost kernel: [ 886.218061] Code: bb 86 da c6 31 c0 c3 90 8d b4 26 00 00 00 00 64 a1 00 f0 3e c0 8b 80 dc 00 00 00 c3 8d 76 00 64 a1 00 f0 3e c0 8b 80 8c 04 00 00 80 2c 01 00 00 ff ff ff ff 64 a1 00 f0 3e c0 81 88 ac 01 00 Oct 2 17:37:13 localhost kernel: [ 886.218083] EIP: [] os_set_mlock_capability+0xc/0x30 [nvidia] SS:ESP 0068:d319bed4 > > but in general there's nothing scheduler-specific about screensavers or > wine - but it could be related to 3D mode of the chip (hence related to > the nvidia module) - do you get a similar lockup if you try to run > 'glxgears'? In fact the backtrace was obtained trying to run glxgears > > Ingo Alejandro -- Nunca discutas con un idiota. Al final te hacen rebajarte a su nivel y
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
> Try setting features to 14. That helps my similar issues. Hi Bill, thanks, but unfortunately that didn't help, with 2.6.23-rc8 it's already set to 29, it happens with 2.6.23-rc8 & with the new scheduler what I found out so far: it definitely is using 3D acceleration: glxgears -info GL_RENDERER = GeForce 7600 GT/PCI/SSE2 GL_VERSION= 2.1.1 NVIDIA 100.14.19 GL_VENDOR = NVIDIA Corporation GL_EXTENSIONS = GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum it's some kind of AIGLX: GLX_EXT_texture_from_pixmap -> nvidia-native handling of compiz * there are no problems with the metacity window manager * it only occurs with compiz being enabled * and it also happens with disabled "fair group cpu scheduler" (with the new scheduler) so it might be a problem with either the graphics driver (tainted !) or the window manager (compiz), compiz-fusion 0.6 will be out soon so I'll check it out if that will help if it gotten clear until now: the old & new cfs scheduler work perfectly fine: no hickups & the like with default window manager (== metacity) so the problem might be somewhere else I'll collect scheduler configuration with the script posted by Ingo in the next following days (pretty busy right now) thanks Mat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Try setting features to 14. That helps my similar issues. Hi Bill, thanks, but unfortunately that didn't help, with 2.6.23-rc8 it's already set to 29, it happens with 2.6.23-rc8 with the new scheduler what I found out so far: it definitely is using 3D acceleration: glxgears -info GL_RENDERER = GeForce 7600 GT/PCI/SSE2 GL_VERSION= 2.1.1 NVIDIA 100.14.19 GL_VENDOR = NVIDIA Corporation GL_EXTENSIONS = GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum it's some kind of AIGLX: GLX_EXT_texture_from_pixmap - nvidia-native handling of compiz * there are no problems with the metacity window manager * it only occurs with compiz being enabled * and it also happens with disabled fair group cpu scheduler (with the new scheduler) so it might be a problem with either the graphics driver (tainted !) or the window manager (compiz), compiz-fusion 0.6 will be out soon so I'll check it out if that will help if it gotten clear until now: the old new cfs scheduler work perfectly fine: no hickups the like with default window manager (== metacity) so the problem might be somewhere else I'll collect scheduler configuration with the script posted by Ingo in the next following days (pretty busy right now) thanks Mat - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
El Sun, 30 Sep 2007 17:26:22 +0200 Ingo Molnar [EMAIL PROTECTED] escribió: hm. There are no similar reports so far. Could you try to run the wine program from a VGA text console (first do 'xhost +' in an xterm under X and then 'export DISPLAY=:0' in the text console) and see whether anything gets output to that console? Also enable nmi_watchdog=2 - which could print a backtrace of the point of the hard lockup. Ignore the last mail there was no need to use pictures this no an oops on boot ;) This is the back trace Oct 2 17:37:13 localhost kernel: [ 886.216868] BUG: unable to handle kernel NULL pointer dereference at virtual address 012c Oct 2 17:37:13 localhost kernel: [ 886.216874] printing eip: Oct 2 17:37:13 localhost kernel: [ 886.216876] f9374d0c Oct 2 17:37:13 localhost kernel: [ 886.216877] *pde = Oct 2 17:37:13 localhost kernel: [ 886.216880] Oops: 0002 [#1] Oct 2 17:37:13 localhost kernel: [ 886.216881] PREEMPT SMP Oct 2 17:37:13 localhost kernel: [ 886.216884] Modules linked in: nls_cp850 isofs udf nls_utf8 ntfs binfmt_misc rfcomm l2cap bluetooth ipt_ULOG x_tables jfs ipv6 dm_crypt af_packet kvm_amd kvm fuse w83627ehf hwmon_vid i2c_dev lp snd_mpu401 snd_mpu401_uart snd_hda_intel snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer nvidia(P) snd_seq_device usbhid i2c_ali15x3 i2c_ali1535 8250_pnp usblp ff_memless uli526x snd i2c_core 8250 serial_core button ali_agp parport_pc parport k8temp hwmon pcspkr evdev rtc snd_page_alloc rt2500 soundcore sg floppy sr_mod raid10 cdrom sd_mod ehci_hcd ohci_hcd ata_generic usbcore raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan unix dm_mod Oct 2 17:37:13 localhost kernel: [ 886.216933] CPU:0 Oct 2 17:37:13 localhost kernel: [ 886.216934] EIP:0060:[f9374d0c] Tainted: PVLI Oct 2 17:37:13 localhost kernel: [ 886.216935] EFLAGS: 00010246 (2.6.23-rc9-cfs-v22-dirty #82) Oct 2 17:37:13 localhost kernel: [ 886.217129] EIP is at os_set_mlock_capability+0xc/0x30 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217131] eax: ebx: ecx: 0050 edx: 0202 Oct 2 17:37:13 localhost kernel: [ 886.217134] esi: f74c3000 edi: f749cc00 ebp: df4b3ff0 esp: d319bed4 Oct 2 17:37:13 localhost kernel: [ 886.217136] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Oct 2 17:37:13 localhost kernel: [ 886.217139] Process spirographx (pid: 5512, ti=d319b000 task=c45da540 task.ti=d319b000) Oct 2 17:37:13 localhost kernel: [ 886.217141] Stack: f909cd35 f909ed92 f9655740 e1d42c00 f6ca5bc0 f90a0c26 df4b2000 005b Oct 2 17:37:13 localhost kernel: [ 886.217146]000c f909da32 f9655740 e1d42c00 005b f6ca5bc0 f6ca5bc0 005b Oct 2 17:37:13 localhost kernel: [ 886.217151]f9655740 f9370e98 df4b2000 f9655740 e1d42c00 005b f6ca5bc0 Oct 2 17:37:13 localhost kernel: [ 886.217157] Call Trace: Oct 2 17:37:13 localhost kernel: [ 886.217164] [f909cd35] _nv002553rm+0x5/0x10 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217259] [f909ed92] rm_write_watch_init+0x3b/0x54 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217365] [f90a0c26] _nv002642rm+0x416/0x5e9 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217469] [f909da32] rm_ioctl+0x3e/0x6d [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217578] [f9370e98] nv_kern_ioctl+0xf8/0x3c0 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217732] [f9371198] nv_kern_unlocked_ioctl+0x18/0x20 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217866] [f9371180] nv_kern_unlocked_ioctl+0x0/0x20 [nvidia] Oct 2 17:37:13 localhost kernel: [ 886.217989] [do_ioctl+43/144] do_ioctl+0x2b/0x90 Oct 2 17:37:13 localhost kernel: [ 886.217994] [remove_vma+57/80] remove_vma+0x39/0x50 Oct 2 17:37:13 localhost kernel: [ 886.218010] [vfs_ioctl+92/656] vfs_ioctl+0x5c/0x290 Oct 2 17:37:13 localhost kernel: [ 886.218022] [sys_ioctl+114/144] sys_ioctl+0x72/0x90 Oct 2 17:37:13 localhost kernel: [ 886.218032] [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 Oct 2 17:37:13 localhost kernel: [ 886.218060] === Oct 2 17:37:13 localhost kernel: [ 886.218061] Code: bb 86 da c6 31 c0 c3 90 8d b4 26 00 00 00 00 64 a1 00 f0 3e c0 8b 80 dc 00 00 00 c3 8d 76 00 64 a1 00 f0 3e c0 8b 80 8c 04 00 00 c7 80 2c 01 00 00 ff ff ff ff 64 a1 00 f0 3e c0 81 88 ac 01 00 Oct 2 17:37:13 localhost kernel: [ 886.218083] EIP: [f9374d0c] os_set_mlock_capability+0xc/0x30 [nvidia] SS:ESP 0068:d319bed4 but in general there's nothing scheduler-specific about screensavers or wine - but it could be related to 3D mode of the chip (hence related to the nvidia module) - do you get a similar lockup if you try to run 'glxgears'? In fact the backtrace was obtained trying to run glxgears Ingo Alejandro -- Nunca
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Matthew wrote: Hi Ingo & everbody on the list, first of all: many thanks for developing this great scheduler (also: kudos to Con Kolivas for having developed SD & CK-patchset) (this is my second mail to this list and I hope I'm doing everything right) I'm doing some backup during work right now: rsyncing my home partition (nearly 180 GB) to another harddrive locally & since I'm running compiz-fusion, openoffice and gnome, therefore am in some real "working environment" I thought: give Ingo's new scheduler a test-ride during heavy load ;) first some impressions: cpu load balancing looks great again (pretty symmetrical loading on both cores - it looks pretty similar to 19.1 if not better if I recall right), v20 wasn't that "good-looking" ;) (with gnome-system-monitor) both cpus have a continous load of ~ 70% right now so I'll be starting up 9 instances of glxgears, below are some output & details of my system (cpu frequency switching is disabled since it doesn't work right now with the current bios version) short summary: unfortunately after starting glxgears everything stuttered a lot, don't know if it's expactable during that heavy load - just wanted to let you know; after having closed each instance of glxgears, everything was fine again ... cat /proc/sched_debug Sched Debug Version: v0.05-v22, 2.6.23-rc8-cfs-v22 #1 now at 3890590.670323 msecs .sysctl_sched_latency: 20.00 .sysctl_sched_nr_latency : 0.20 .sysctl_sched_wakeup_granularity : 2.00 .sysctl_sched_batch_wakeup_granularity : 25.00 .sysctl_sched_child_runs_first : 0.01 .sysctl_sched_features : 3 Try setting features to 14. That helps my similar issues. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* Matthew <[EMAIL PROTECTED]> wrote: > Thanks for your answer (sorry, I didn't know your email had changed) > > well, this will take some time since I don't work every day & it's > turned off most of the time, hope that is OK > > before I proceed with that data-collection: > > do you think it is possible that it might be related to "Fair group > CPU scheduler" being selected ? i think if you are relatively sure that the box does not have any real 3D hardware in it (supported by X) then glxgears will interact badly with X and can cause such symptoms. In that case glxgears 'spams' the X server with requests and everyone else suffers from that. The fair-group scheduler indeed could shift CPU usage of X just enough (in X's favor!) that might trigger such problems. Such "spam X" workloads often react in a paradoxial way: a scheduler that gives X _more_ CPU time will appear to be "less interactive".) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Thanks for your answer (sorry, I didn't know your email had changed) well, this will take some time since I don't work every day & it's turned off most of the time, hope that is OK before I proceed with that data-collection: do you think it is possible that it might be related to "Fair group CPU scheduler" being selected ? I think that one and another additional option (don't know right now its name, but will look for it later) was the only difference on the .config-file between 2.6.23-rc8 & 2.6.23-rc8-git3 (+ sched-devel) Mat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* Matthew <[EMAIL PROTECTED]> wrote: > both cpus have a continous load of ~ 70% right now so I'll be starting > up 9 instances of glxgears, below are some output & details of my > system (cpu frequency switching is disabled since it doesn't work > right now with the current bios version) > > short summary: unfortunately after starting glxgears everything > stuttered a lot, don't know if it's expactable during that heavy load > - just wanted to let you know; after having closed each instance of > glxgears, everything was fine again ... > cpu#0, 2404.249 MHz > cpu#1, 2404.249 MHz > result: most times only 2-3 of the glxgears-windows were running, the > rest was stuttering / halting (no motion) mouse movement was pretty > discountinous, keyboard input was also delayed how does it behave without the cfs patch applied? Does it work better under v20.5? The best debug output for me to look at would be to download these two scripts: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info-clear.sh first run cfs-debug-info-clear.sh, then use the system for a few minutes and make sure apps are behaving in a 'stutter-free' way. Then run cfs-debug-info.sh (still no glxgears running) - it will produce a "no load" debug info file. Then start the 9x glxgears instances, reproduce the "stuttering" behavior in the apps, and run cfs-debug-info.sh - this will produce a second "under load" output file. Please send me both output files. also, what's the output of "glxgears -info" - does it render on real 3D hardware, or uses the sw-mesa fallback? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* Alejandro Riveira Fernández <[EMAIL PROTECTED]> wrote: > > Even if CFS v20.5 worked well for you, please try this release too, with > > a good focus on interactivity testing - because, unless some major > > showstopper is found, this codebase is intended for a v2.6.24 upstream > > merge. > > > > ( Even a quick, subjective report of: "checked this patch, it didnt > > crash and it feels like v20.5" or "laggier than v20.5" or "feels > > better than v20.5" is useful to us and enables us to judge the general > > direction of interactivity. ) > > I feel it better than 20.5 but the later is more stable. Let me > explain. > > I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With > the 22 version if i lock the screen (run screensaver) or i try to run > a wine program i experience a hard lock up no keyboard or mouse and i > have to reboot the machine (i can not try to access it via ssh > because i do not have a second machine). I run with the nvidia kernel > module so I know my report is useless but just for the record... Here > it is my config: hm. There are no similar reports so far. Could you try to run the wine program from a VGA text console (first do 'xhost +' in an xterm under X and then 'export DISPLAY=:0' in the text console) and see whether anything gets output to that console? Also enable nmi_watchdog=2 - which could print a backtrace of the point of the hard lockup. but in general there's nothing scheduler-specific about screensavers or wine - but it could be related to 3D mode of the chip (hence related to the nvidia module) - do you get a similar lockup if you try to run 'glxgears'? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* Alejandro Riveira Fernández [EMAIL PROTECTED] wrote: Even if CFS v20.5 worked well for you, please try this release too, with a good focus on interactivity testing - because, unless some major showstopper is found, this codebase is intended for a v2.6.24 upstream merge. ( Even a quick, subjective report of: checked this patch, it didnt crash and it feels like v20.5 or laggier than v20.5 or feels better than v20.5 is useful to us and enables us to judge the general direction of interactivity. ) I feel it better than 20.5 but the later is more stable. Let me explain. I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 version if i lock the screen (run screensaver) or i try to run a wine program i experience a hard lock up no keyboard or mouse and i have to reboot the machine (i can not try to access it via ssh because i do not have a second machine). I run with the nvidia kernel module so I know my report is useless but just for the record... Here it is my config: hm. There are no similar reports so far. Could you try to run the wine program from a VGA text console (first do 'xhost +' in an xterm under X and then 'export DISPLAY=:0' in the text console) and see whether anything gets output to that console? Also enable nmi_watchdog=2 - which could print a backtrace of the point of the hard lockup. but in general there's nothing scheduler-specific about screensavers or wine - but it could be related to 3D mode of the chip (hence related to the nvidia module) - do you get a similar lockup if you try to run 'glxgears'? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* Matthew [EMAIL PROTECTED] wrote: both cpus have a continous load of ~ 70% right now so I'll be starting up 9 instances of glxgears, below are some output details of my system (cpu frequency switching is disabled since it doesn't work right now with the current bios version) short summary: unfortunately after starting glxgears everything stuttered a lot, don't know if it's expactable during that heavy load - just wanted to let you know; after having closed each instance of glxgears, everything was fine again ... cpu#0, 2404.249 MHz cpu#1, 2404.249 MHz result: most times only 2-3 of the glxgears-windows were running, the rest was stuttering / halting (no motion) mouse movement was pretty discountinous, keyboard input was also delayed how does it behave without the cfs patch applied? Does it work better under v20.5? The best debug output for me to look at would be to download these two scripts: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info-clear.sh first run cfs-debug-info-clear.sh, then use the system for a few minutes and make sure apps are behaving in a 'stutter-free' way. Then run cfs-debug-info.sh (still no glxgears running) - it will produce a no load debug info file. Then start the 9x glxgears instances, reproduce the stuttering behavior in the apps, and run cfs-debug-info.sh - this will produce a second under load output file. Please send me both output files. also, what's the output of glxgears -info - does it render on real 3D hardware, or uses the sw-mesa fallback? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Thanks for your answer (sorry, I didn't know your email had changed) well, this will take some time since I don't work every day it's turned off most of the time, hope that is OK before I proceed with that data-collection: do you think it is possible that it might be related to Fair group CPU scheduler being selected ? I think that one and another additional option (don't know right now its name, but will look for it later) was the only difference on the .config-file between 2.6.23-rc8 2.6.23-rc8-git3 (+ sched-devel) Mat - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* Matthew [EMAIL PROTECTED] wrote: Thanks for your answer (sorry, I didn't know your email had changed) well, this will take some time since I don't work every day it's turned off most of the time, hope that is OK before I proceed with that data-collection: do you think it is possible that it might be related to Fair group CPU scheduler being selected ? i think if you are relatively sure that the box does not have any real 3D hardware in it (supported by X) then glxgears will interact badly with X and can cause such symptoms. In that case glxgears 'spams' the X server with requests and everyone else suffers from that. The fair-group scheduler indeed could shift CPU usage of X just enough (in X's favor!) that might trigger such problems. Such spam X workloads often react in a paradoxial way: a scheduler that gives X _more_ CPU time will appear to be less interactive.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Matthew wrote: Hi Ingo everbody on the list, first of all: many thanks for developing this great scheduler (also: kudos to Con Kolivas for having developed SD CK-patchset) (this is my second mail to this list and I hope I'm doing everything right) I'm doing some backup during work right now: rsyncing my home partition (nearly 180 GB) to another harddrive locally since I'm running compiz-fusion, openoffice and gnome, therefore am in some real working environment I thought: give Ingo's new scheduler a test-ride during heavy load ;) first some impressions: cpu load balancing looks great again (pretty symmetrical loading on both cores - it looks pretty similar to 19.1 if not better if I recall right), v20 wasn't that good-looking ;) (with gnome-system-monitor) both cpus have a continous load of ~ 70% right now so I'll be starting up 9 instances of glxgears, below are some output details of my system (cpu frequency switching is disabled since it doesn't work right now with the current bios version) short summary: unfortunately after starting glxgears everything stuttered a lot, don't know if it's expactable during that heavy load - just wanted to let you know; after having closed each instance of glxgears, everything was fine again ... cat /proc/sched_debug Sched Debug Version: v0.05-v22, 2.6.23-rc8-cfs-v22 #1 now at 3890590.670323 msecs .sysctl_sched_latency: 20.00 .sysctl_sched_nr_latency : 0.20 .sysctl_sched_wakeup_granularity : 2.00 .sysctl_sched_batch_wakeup_granularity : 25.00 .sysctl_sched_child_runs_first : 0.01 .sysctl_sched_features : 3 Try setting features to 14. That helps my similar issues. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
El Fri, 28 Sep 2007 23:20:13 -0300 Henrique de Moraes Holschuh <[EMAIL PROTECTED]> escribió: > On Fri, 28 Sep 2007, Alejandro Riveira Fernández wrote: > > I feel it better than 20.5 but the later is more stable. Let me explain. > > > > I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 > > version if i lock the screen (run screensaver) or i try to run a wine > > program > > i experience a hard lock up no keyboard or mouse and i have to reboot the > > machine (i can not try to access it via ssh because i do not have a second > > machine). > Thanks for the response :D > I have seen that twice with v20.5 under 2.6.22.7/.8. Didn't see it yet with > v22. xterm would get pissed if I tried to "secure keyboard", so something > stole the keyboard focus and wouldn't give it back to xorg. Maybe a locking > bug in xorg somewhere? > > Anyway, my kernel is NOT tainted, so rest assured that at least this one is > not nVidia's fault. > > BTW, v20.5 in 2.6.21.7 would sometimes cause dmcrypt to oops when first > mounting a LUKS volume if there was some non-extra-light disk activity going > on. Probably something missing in the backport to 2.6.21... > > Sorry, days down here have been very busy, so I didn't have time to send a > proper bug report. I can add another data point 2.6.23-rc8-cfs-v22-g1bef7dc0-dirty does not have any problem with wine or xscreensaver is working fine. Again i use nvidia and a 3 party gpl driver for my wifi rt2500 which have compiled fine with the new kernel (surprise surprise!) If you need any more info just ask. Thanks P.S: I use ubuntu feisty fwiw -- Nunca discutas con un idiota. Al final te hacen rebajarte a su nivel y entonces te acaban ganando debido a su mayor experiencia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Hi Ingo & everbody on the list, first of all: many thanks for developing this great scheduler (also: kudos to Con Kolivas for having developed SD & CK-patchset) (this is my second mail to this list and I hope I'm doing everything right) I'm doing some backup during work right now: rsyncing my home partition (nearly 180 GB) to another harddrive locally & since I'm running compiz-fusion, openoffice and gnome, therefore am in some real "working environment" I thought: give Ingo's new scheduler a test-ride during heavy load ;) first some impressions: cpu load balancing looks great again (pretty symmetrical loading on both cores - it looks pretty similar to 19.1 if not better if I recall right), v20 wasn't that "good-looking" ;) (with gnome-system-monitor) both cpus have a continous load of ~ 70% right now so I'll be starting up 9 instances of glxgears, below are some output & details of my system (cpu frequency switching is disabled since it doesn't work right now with the current bios version) short summary: unfortunately after starting glxgears everything stuttered a lot, don't know if it's expactable during that heavy load - just wanted to let you know; after having closed each instance of glxgears, everything was fine again ... cat /proc/sched_debug Sched Debug Version: v0.05-v22, 2.6.23-rc8-cfs-v22 #1 now at 3890590.670323 msecs .sysctl_sched_latency: 20.00 .sysctl_sched_nr_latency : 0.20 .sysctl_sched_wakeup_granularity : 2.00 .sysctl_sched_batch_wakeup_granularity : 25.00 .sysctl_sched_child_runs_first : 0.01 .sysctl_sched_features : 3 cpu#0, 2404.249 MHz .nr_running: 4 .load : 4096 .nr_switches : 7648325 .nr_load_updates : 2103023 .nr_uninterruptible: 58007 .jiffies : 3590591 .next_balance : 3.590615 .curr->pid : 4942 .clock : 2102704.853484 .idle_clock: 0.00 .prev_clock_raw: 3939505.166968 .clock_warps : 0 .clock_overflows : 1525057 .clock_deep_idle_events: 0 .clock_max_delta : 0.999846 .cpu_load[0] : 3072 .cpu_load[1] : 3148 .cpu_load[2] : 3448 .cpu_load[3] : 3598 .cpu_load[4] : 3612 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 705800.821444 .min_vruntime : 705800.818396 .max_vruntime : 705800.821444 .spread: 0.00 .spread0 : 0.00 .nr_running: 2 .load : 3072 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 114142.324354 .min_vruntime : 705800.818396 .max_vruntime : 114142.460206 .spread: 0.135852 .spread0 : 0.00 .nr_running: 3 .load : 3072 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 0.01 .min_vruntime : 705800.818396 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 0 .load : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 0.01 .min_vruntime : 705800.818396 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 0 .load : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 0.01 .min_vruntime : 705800.818396 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 1 .load : 1024 .nr_spread_over: 0 runnable tasks: task PID tree-key switches prio exec-runtime sum-execsum-sleep -- X 4043114142.410694 1413252 120 0 0 0.00 0.00 0.00 glxgears 4938114142.460206251121 120 0 0 0.00 0.00
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
Hi Ingo everbody on the list, first of all: many thanks for developing this great scheduler (also: kudos to Con Kolivas for having developed SD CK-patchset) (this is my second mail to this list and I hope I'm doing everything right) I'm doing some backup during work right now: rsyncing my home partition (nearly 180 GB) to another harddrive locally since I'm running compiz-fusion, openoffice and gnome, therefore am in some real working environment I thought: give Ingo's new scheduler a test-ride during heavy load ;) first some impressions: cpu load balancing looks great again (pretty symmetrical loading on both cores - it looks pretty similar to 19.1 if not better if I recall right), v20 wasn't that good-looking ;) (with gnome-system-monitor) both cpus have a continous load of ~ 70% right now so I'll be starting up 9 instances of glxgears, below are some output details of my system (cpu frequency switching is disabled since it doesn't work right now with the current bios version) short summary: unfortunately after starting glxgears everything stuttered a lot, don't know if it's expactable during that heavy load - just wanted to let you know; after having closed each instance of glxgears, everything was fine again ... cat /proc/sched_debug Sched Debug Version: v0.05-v22, 2.6.23-rc8-cfs-v22 #1 now at 3890590.670323 msecs .sysctl_sched_latency: 20.00 .sysctl_sched_nr_latency : 0.20 .sysctl_sched_wakeup_granularity : 2.00 .sysctl_sched_batch_wakeup_granularity : 25.00 .sysctl_sched_child_runs_first : 0.01 .sysctl_sched_features : 3 cpu#0, 2404.249 MHz .nr_running: 4 .load : 4096 .nr_switches : 7648325 .nr_load_updates : 2103023 .nr_uninterruptible: 58007 .jiffies : 3590591 .next_balance : 3.590615 .curr-pid : 4942 .clock : 2102704.853484 .idle_clock: 0.00 .prev_clock_raw: 3939505.166968 .clock_warps : 0 .clock_overflows : 1525057 .clock_deep_idle_events: 0 .clock_max_delta : 0.999846 .cpu_load[0] : 3072 .cpu_load[1] : 3148 .cpu_load[2] : 3448 .cpu_load[3] : 3598 .cpu_load[4] : 3612 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 705800.821444 .min_vruntime : 705800.818396 .max_vruntime : 705800.821444 .spread: 0.00 .spread0 : 0.00 .nr_running: 2 .load : 3072 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 114142.324354 .min_vruntime : 705800.818396 .max_vruntime : 114142.460206 .spread: 0.135852 .spread0 : 0.00 .nr_running: 3 .load : 3072 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 0.01 .min_vruntime : 705800.818396 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 0 .load : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 0.01 .min_vruntime : 705800.818396 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 0 .load : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 0.00 .MIN_vruntime : 0.01 .min_vruntime : 705800.818396 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 1 .load : 1024 .nr_spread_over: 0 runnable tasks: task PID tree-key switches prio exec-runtime sum-execsum-sleep -- X 4043114142.410694 1413252 120 0 0 0.00 0.00 0.00 glxgears 4938114142.460206251121 120 0 0 0.00 0.00 0.00
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
El Fri, 28 Sep 2007 23:20:13 -0300 Henrique de Moraes Holschuh [EMAIL PROTECTED] escribió: On Fri, 28 Sep 2007, Alejandro Riveira Fernández wrote: I feel it better than 20.5 but the later is more stable. Let me explain. I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 version if i lock the screen (run screensaver) or i try to run a wine program i experience a hard lock up no keyboard or mouse and i have to reboot the machine (i can not try to access it via ssh because i do not have a second machine). Thanks for the response :D I have seen that twice with v20.5 under 2.6.22.7/.8. Didn't see it yet with v22. xterm would get pissed if I tried to secure keyboard, so something stole the keyboard focus and wouldn't give it back to xorg. Maybe a locking bug in xorg somewhere? Anyway, my kernel is NOT tainted, so rest assured that at least this one is not nVidia's fault. BTW, v20.5 in 2.6.21.7 would sometimes cause dmcrypt to oops when first mounting a LUKS volume if there was some non-extra-light disk activity going on. Probably something missing in the backport to 2.6.21... Sorry, days down here have been very busy, so I didn't have time to send a proper bug report. I can add another data point 2.6.23-rc8-cfs-v22-g1bef7dc0-dirty does not have any problem with wine or xscreensaver is working fine. Again i use nvidia and a 3 party gpl driver for my wifi rt2500 which have compiled fine with the new kernel (surprise surprise!) If you need any more info just ask. Thanks P.S: I use ubuntu feisty fwiw -- Nunca discutas con un idiota. Al final te hacen rebajarte a su nivel y entonces te acaban ganando debido a su mayor experiencia. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
On Fri, 28 Sep 2007, Alejandro Riveira Fernández wrote: > I feel it better than 20.5 but the later is more stable. Let me explain. > > I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 > version if i lock the screen (run screensaver) or i try to run a wine program > i experience a hard lock up no keyboard or mouse and i have to reboot the > machine (i can not try to access it via ssh because i do not have a second > machine). I have seen that twice with v20.5 under 2.6.22.7/.8. Didn't see it yet with v22. xterm would get pissed if I tried to "secure keyboard", so something stole the keyboard focus and wouldn't give it back to xorg. Maybe a locking bug in xorg somewhere? Anyway, my kernel is NOT tainted, so rest assured that at least this one is not nVidia's fault. BTW, v20.5 in 2.6.21.7 would sometimes cause dmcrypt to oops when first mounting a LUKS volume if there was some non-extra-light disk activity going on. Probably something missing in the backport to 2.6.21... Sorry, days down here have been very busy, so I didn't have time to send a proper bug report. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
El Wed, 26 Sep 2007 13:13:57 +0200 Ingo Molnar <[EMAIL PROTECTED]> escribió: > By popular demand, here is release -v22 of the CFS scheduler. It is a > full backport of the latest & greatest sched-devel.git code to > v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be > downloaded from the usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > This is the first time the development version of the scheduler has been > fed back into the stable backport series, so there's many changes since > v20.5: > > 15 files changed, 1103 insertions(+), 840 deletions(-) Thanks for the effort, much apreciated. > > Even if CFS v20.5 worked well for you, please try this release too, with > a good focus on interactivity testing - because, unless some major > showstopper is found, this codebase is intended for a v2.6.24 upstream > merge. > > ( Even a quick, subjective report of: "checked this patch, it didnt > crash and it feels like v20.5" or "laggier than v20.5" or "feels > better than v20.5" is useful to us and enables us to judge the general > direction of interactivity. ) I feel it better than 20.5 but the later is more stable. Let me explain. I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 version if i lock the screen (run screensaver) or i try to run a wine program i experience a hard lock up no keyboard or mouse and i have to reboot the machine (i can not try to access it via ssh because i do not have a second machine). I run with the nvidia kernel module so I know my report is useless but just for the record... Here it is my config: [1] Hand edited the Makefile hunk no other rejects # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.9-cfs-v20.5 # Fri Sep 28 16:12:07 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEBUG is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
El Wed, 26 Sep 2007 13:13:57 +0200 Ingo Molnar [EMAIL PROTECTED] escribió: By popular demand, here is release -v22 of the CFS scheduler. It is a full backport of the latest greatest sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ This is the first time the development version of the scheduler has been fed back into the stable backport series, so there's many changes since v20.5: 15 files changed, 1103 insertions(+), 840 deletions(-) Thanks for the effort, much apreciated. Even if CFS v20.5 worked well for you, please try this release too, with a good focus on interactivity testing - because, unless some major showstopper is found, this codebase is intended for a v2.6.24 upstream merge. ( Even a quick, subjective report of: checked this patch, it didnt crash and it feels like v20.5 or laggier than v20.5 or feels better than v20.5 is useful to us and enables us to judge the general direction of interactivity. ) I feel it better than 20.5 but the later is more stable. Let me explain. I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 version if i lock the screen (run screensaver) or i try to run a wine program i experience a hard lock up no keyboard or mouse and i have to reboot the machine (i can not try to access it via ssh because i do not have a second machine). I run with the nvidia kernel module so I know my report is useless but just for the record... Here it is my config: [1] Hand edited the Makefile hunk no other rejects # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.9-cfs-v20.5 # Fri Sep 28 16:12:07 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEBUG is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set #
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
On Fri, 28 Sep 2007, Alejandro Riveira Fernández wrote: I feel it better than 20.5 but the later is more stable. Let me explain. I patched a 2.6.22.9 kernel with both versions 22 and 20.5[1]. With the 22 version if i lock the screen (run screensaver) or i try to run a wine program i experience a hard lock up no keyboard or mouse and i have to reboot the machine (i can not try to access it via ssh because i do not have a second machine). I have seen that twice with v20.5 under 2.6.22.7/.8. Didn't see it yet with v22. xterm would get pissed if I tried to secure keyboard, so something stole the keyboard focus and wouldn't give it back to xorg. Maybe a locking bug in xorg somewhere? Anyway, my kernel is NOT tainted, so rest assured that at least this one is not nVidia's fault. BTW, v20.5 in 2.6.21.7 would sometimes cause dmcrypt to oops when first mounting a LUKS volume if there was some non-extra-light disk activity going on. Probably something missing in the backport to 2.6.21... Sorry, days down here have been very busy, so I didn't have time to send a proper bug report. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote: > Compilation [against 2.6.20.20] fails with > > buildfarm linux-2.6.20 # make > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CHK include/linux/compile.h > CC kernel/sched.o > In file included from kernel/sched.c:850: > kernel/sched_fair.c:49: error: sysctl_sched_nr_latency causes a section type > conflict > make[1]: *** [kernel/sched.o] Error 1 > make: *** [kernel] Error 2 oops, indeed! This happens with certain .config combinations only and it didnt trigger on mine. > @kernel/sched_fair.c > -const_debug unsigned int sysctl_sched_nr_latency __read_mostly = 20; > +const_debug unsigned int sysctl_sched_nr_latency = 20; > > seems solve that issue but i'm not sure this is the right thing to do > or not :) your fix is the right one - and i've updated the patches with this small fix. Anyone who hits this issue should re-download the same patch once more, or should apply the small patch below. Ingo Index: linux/kernel/sched_fair.c === --- linux.orig/kernel/sched_fair.c +++ linux/kernel/sched_fair.c @@ -46,7 +46,7 @@ const_debug unsigned int sysctl_sched_ch * Minimal preemption granularity for CPU-bound tasks: * (default: 2 msec, units: nanoseconds) */ -const_debug unsigned int sysctl_sched_nr_latency __read_mostly = 20; +const_debug unsigned int sysctl_sched_nr_latency = 20; /* * sys_sched_yield() compat mode - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
26 Eyl 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı: > By popular demand, here is release -v22 of the CFS scheduler. It is a > full backport of the latest & greatest sched-devel.git code to > v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be > downloaded from the usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > This is the first time the development version of the scheduler has been > fed back into the stable backport series, so there's many changes since > v20.5: Compilation [against 2.6.20.20] fails with buildfarm linux-2.6.20 # make CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC kernel/sched.o In file included from kernel/sched.c:850: kernel/sched_fair.c:49: error: sysctl_sched_nr_latency causes a section type conflict make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 @kernel/sched_fair.c -const_debug unsigned int sysctl_sched_nr_latency __read_mostly = 20; +const_debug unsigned int sysctl_sched_nr_latency = 20; seems solve that issue but i'm not sure this is the right thing to do or not :) Cheers -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
By popular demand, here is release -v22 of the CFS scheduler. It is a full backport of the latest & greatest sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ This is the first time the development version of the scheduler has been fed back into the stable backport series, so there's many changes since v20.5: 15 files changed, 1103 insertions(+), 840 deletions(-) Even if CFS v20.5 worked well for you, please try this release too, with a good focus on interactivity testing - because, unless some major showstopper is found, this codebase is intended for a v2.6.24 upstream merge. ( Even a quick, subjective report of: "checked this patch, it didnt crash and it feels like v20.5" or "laggier than v20.5" or "feels better than v20.5" is useful to us and enables us to judge the general direction of interactivity. ) The changes in v22 consist of lots of mostly small enhancements, speedups, interactivity improvements, debug enhancements and tidy-ups - many of which can be user-visible. (These enhancements have been contributed by many people - see the changelog below and the git tree for detailed credits.) The biggest individual new feature is per UID group scheduling, written by Srivatsa Vaddagiri, which can be enabled via the CONFIG_FAIR_USER_SCHED=y .config option. With this feature enabled, each user gets a fair share of the CPU time, regardless of how many tasks each user is running. For example, it took me 0.1 seconds to log in over ssh as root on a testbox that was running a kernel with per UID group scheduling enabled: $ time ssh [EMAIL PROTECTED] /bin/true real0m0.125s user0m0.013s sys 0m0.011s Which testbox had a system load of 1000.17 at this time, due to a rogue runaway workload of one thousand (!) non-reniced infinite loops: top - 14:34:05 up 30 min, 3 users, load average: 1000.17, 839.23, 444.57 Tasks: 1131 total, 1002 running, 129 sleeping, 0 stopped, 0 zombie Cpu(s): 30.8%us, 0.2%sy, 0.0%ni, 68.2%id, 0.8%wa, 0.0%hi, 0.0%si Mem: 2048992k total, 157688k used, 1891304k free,18308k buffers Swap: 4096564k total,0k used, 4096564k free,25464k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3633 root 20 0 2892 1576 724 R7 0.1 0:00.06 top 2427 mingo 20 0 1576 244 196 R2 0.0 0:01.14 loop 2429 mingo 20 0 1576 244 196 R2 0.0 0:01.14 loop To the root user, the box was fully usable an interactivity was excellent - i was easily able to kill off those runaway tasks. ( The /proc/root_user_cpu_share tunable also allows the root uid to have higher weight than other uids. Unit of the tunable is 0.1%, a weight of 100% is 1024, the default weight of the root uid is 200%. ) See the detailed shortlog below for a description of the other changes, or pull the sched-devel.git tree for all the 83 commits: git-pull git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git Also, as usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Ingo --> Dmitry Adamushko (9): sched: clean up struct load_stat sched: clean up schedstat block in dequeue_entity() sched: sched_setscheduler() fix sched: add set_curr_task() calls sched: do not keep current in the tree and get rid of sched_entity::fair_key sched: optimize task_new_fair() sched: simplify sched_class::yield_task() sched: rework enqueue/dequeue_entity() to get rid of set_curr_task() sched: yield fix Hiroshi Shimamoto (1): sched: clean up sched_fork() Matthias Kaehlcke (1): sched: use list_for_each_entry_safe() in __wake_up_common() Mike Galbraith (2): sched: fix SMP migration latencies sched: fix formatting of /proc/sched_debug Peter Zijlstra (12): sched: simplify SCHED_FEAT_* code sched: new task placement for vruntime sched: simplify adaptive latency sched: clean up new task placement sched: add tree based averages sched: handle vruntime overflow sched: better min_vruntime tracking sched: add vslice sched debug: check spread sched: max_vruntime() simplification sched: clean up min_vruntime use sched: speed up and simplify vslice calculations S.Caglar Onur (1): sched debug: BKL usage statistics, fix Srivatsa Vaddagiri (12): sched: group-scheduler core sched: revert recent removal of set_curr_task() sched: fix minor bug in yield sched: print nr_running and load in /proc/sched_debug sched: print >cfs stats sched: clean up code under CONFIG_FAIR_GROUP_SCHED sched: add fair-user scheduler sched: group scheduler wakeup latency fix sched: group scheduler SMP migration fix
[patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
By popular demand, here is release -v22 of the CFS scheduler. It is a full backport of the latest greatest sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ This is the first time the development version of the scheduler has been fed back into the stable backport series, so there's many changes since v20.5: 15 files changed, 1103 insertions(+), 840 deletions(-) Even if CFS v20.5 worked well for you, please try this release too, with a good focus on interactivity testing - because, unless some major showstopper is found, this codebase is intended for a v2.6.24 upstream merge. ( Even a quick, subjective report of: checked this patch, it didnt crash and it feels like v20.5 or laggier than v20.5 or feels better than v20.5 is useful to us and enables us to judge the general direction of interactivity. ) The changes in v22 consist of lots of mostly small enhancements, speedups, interactivity improvements, debug enhancements and tidy-ups - many of which can be user-visible. (These enhancements have been contributed by many people - see the changelog below and the git tree for detailed credits.) The biggest individual new feature is per UID group scheduling, written by Srivatsa Vaddagiri, which can be enabled via the CONFIG_FAIR_USER_SCHED=y .config option. With this feature enabled, each user gets a fair share of the CPU time, regardless of how many tasks each user is running. For example, it took me 0.1 seconds to log in over ssh as root on a testbox that was running a kernel with per UID group scheduling enabled: $ time ssh [EMAIL PROTECTED] /bin/true real0m0.125s user0m0.013s sys 0m0.011s Which testbox had a system load of 1000.17 at this time, due to a rogue runaway workload of one thousand (!) non-reniced infinite loops: top - 14:34:05 up 30 min, 3 users, load average: 1000.17, 839.23, 444.57 Tasks: 1131 total, 1002 running, 129 sleeping, 0 stopped, 0 zombie Cpu(s): 30.8%us, 0.2%sy, 0.0%ni, 68.2%id, 0.8%wa, 0.0%hi, 0.0%si Mem: 2048992k total, 157688k used, 1891304k free,18308k buffers Swap: 4096564k total,0k used, 4096564k free,25464k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3633 root 20 0 2892 1576 724 R7 0.1 0:00.06 top 2427 mingo 20 0 1576 244 196 R2 0.0 0:01.14 loop 2429 mingo 20 0 1576 244 196 R2 0.0 0:01.14 loop To the root user, the box was fully usable an interactivity was excellent - i was easily able to kill off those runaway tasks. ( The /proc/root_user_cpu_share tunable also allows the root uid to have higher weight than other uids. Unit of the tunable is 0.1%, a weight of 100% is 1024, the default weight of the root uid is 200%. ) See the detailed shortlog below for a description of the other changes, or pull the sched-devel.git tree for all the 83 commits: git-pull git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git Also, as usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Ingo -- Dmitry Adamushko (9): sched: clean up struct load_stat sched: clean up schedstat block in dequeue_entity() sched: sched_setscheduler() fix sched: add set_curr_task() calls sched: do not keep current in the tree and get rid of sched_entity::fair_key sched: optimize task_new_fair() sched: simplify sched_class::yield_task() sched: rework enqueue/dequeue_entity() to get rid of set_curr_task() sched: yield fix Hiroshi Shimamoto (1): sched: clean up sched_fork() Matthias Kaehlcke (1): sched: use list_for_each_entry_safe() in __wake_up_common() Mike Galbraith (2): sched: fix SMP migration latencies sched: fix formatting of /proc/sched_debug Peter Zijlstra (12): sched: simplify SCHED_FEAT_* code sched: new task placement for vruntime sched: simplify adaptive latency sched: clean up new task placement sched: add tree based averages sched: handle vruntime overflow sched: better min_vruntime tracking sched: add vslice sched debug: check spread sched: max_vruntime() simplification sched: clean up min_vruntime use sched: speed up and simplify vslice calculations S.Caglar Onur (1): sched debug: BKL usage statistics, fix Srivatsa Vaddagiri (12): sched: group-scheduler core sched: revert recent removal of set_curr_task() sched: fix minor bug in yield sched: print nr_running and load in /proc/sched_debug sched: print rq-cfs stats sched: clean up code under CONFIG_FAIR_GROUP_SCHED sched: add fair-user scheduler sched: group scheduler wakeup latency fix sched: group scheduler SMP migration fix sched:
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
26 Eyl 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı: By popular demand, here is release -v22 of the CFS scheduler. It is a full backport of the latest greatest sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ This is the first time the development version of the scheduler has been fed back into the stable backport series, so there's many changes since v20.5: Compilation [against 2.6.20.20] fails with buildfarm linux-2.6.20 # make CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC kernel/sched.o In file included from kernel/sched.c:850: kernel/sched_fair.c:49: error: sysctl_sched_nr_latency causes a section type conflict make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 @kernel/sched_fair.c -const_debug unsigned int sysctl_sched_nr_latency __read_mostly = 20; +const_debug unsigned int sysctl_sched_nr_latency = 20; seems solve that issue but i'm not sure this is the right thing to do or not :) Cheers -- S.Çağlar Onur [EMAIL PROTECTED] http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8, v2.6.21.7, v2.6.20.20
* S.Çağlar Onur [EMAIL PROTECTED] wrote: Compilation [against 2.6.20.20] fails with buildfarm linux-2.6.20 # make CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC kernel/sched.o In file included from kernel/sched.c:850: kernel/sched_fair.c:49: error: sysctl_sched_nr_latency causes a section type conflict make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 oops, indeed! This happens with certain .config combinations only and it didnt trigger on mine. @kernel/sched_fair.c -const_debug unsigned int sysctl_sched_nr_latency __read_mostly = 20; +const_debug unsigned int sysctl_sched_nr_latency = 20; seems solve that issue but i'm not sure this is the right thing to do or not :) your fix is the right one - and i've updated the patches with this small fix. Anyone who hits this issue should re-download the same patch once more, or should apply the small patch below. Ingo Index: linux/kernel/sched_fair.c === --- linux.orig/kernel/sched_fair.c +++ linux/kernel/sched_fair.c @@ -46,7 +46,7 @@ const_debug unsigned int sysctl_sched_ch * Minimal preemption granularity for CPU-bound tasks: * (default: 2 msec, units: nanoseconds) */ -const_debug unsigned int sysctl_sched_nr_latency __read_mostly = 20; +const_debug unsigned int sysctl_sched_nr_latency = 20; /* * sys_sched_yield() compat mode - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
