vivid-sources

[fallow]

hm I`m prefer nvagp also , but with many of differnt patches I still have black screen....maybe I`ts time to do all , once again hehe

Anyway, vv_e2 is humming along very nicely here. Kudos.

I`m very happy

Your patchset really deserves to be better known. I think we'd all better learn Polish ASAP.

hehe Yes Many of countries on the whole world uses Polish : Poland..... , hm , ......Poland..... and I`m not sure but , I think Poland also

greetings

[fallow]

ok , new vv_e based on 2.6.10-rc2. I think is good idea to stay with on O)1 CPU Scheduler partial mm fixes/patches.

main mission objectives :
- 2.6.10-rc2 with O)1 cpu sched + mm fixes.
- fbsplash , vesa_rrc/tng selectable via USE
- reiser4 from latest mm`s + fixes
- partial fixes/speed-up`s from mm.

"vesa_rrc" - vesa_rrc
"vesa_tng" - vesa tng

list :

Code: Select all

Default CPU Scheduler : O)1 + partial mm patches
Default IO Scheduler selectable from menuconfig : Deadline
--base--
2.6.10-rc2-nvidia-fix.diff
2610rc2_temp-fbsplash.diff
cddvd-cmdfilter-drop.patch
config_hz.diff
configurable-hid-mouse-polling-2.6.9-rc2.patch
iosched_def_sel.diff
lufs.diff
shfs_good_035.patch
supermount-ng207.diff
* vesa_rrc.patch.bz2
* vesa_tng.patch.bz2
*selectable via USE flags.
--mm part--
reiser4+all fixes from latest mm ;)
sched-active_load_balance-fixlet.patch
sched-add_requeue_task.patch
sched-adjust_timeslice_granularity.patch
sched-alter_kthread_prio.patch
sched-can_migrate-exception-for-idle-cpus.patch
sched-ext3-fix-scheduling-latencies-in-ext3.patch
sched-fix-scheduling-latencies-for-preempt-kernels.patch
sched-fix-scheduling-latencies-in-mttrc.patch
sched-mm-fix-scheduling-latencies-in-get_user_pages.patch
sched-mm-fix-scheduling-latencies-in-unmap_vmas.patch
sched-more-agressive-wake_idle.patch
sched-newidle-fix.patch
sched-remove_interactive_credit.patch
sched-reset-cache_hot_time.patch
sched-use-cached-current-value.patch
sched-vfs-fix-scheduling-latencies-in-prune_dcache-and-select_parent-fix.patch
sched-vfs-fix-scheduling-latencies-in-prune_dcache-and-select_parent.patch
add-cpu_relax-in-spin-loops-clean-up-barrier-for-269.patch
add-sysctl-interface-to-sched_domain-parameters.patch
allow-modular-ide-pnp.patch
bk-acpi.patch
bk-ide-dev.patch
bk-netdev.patch
break-latency-in-invalidate_list.patch
detect-atomic-counter-underflows.patch
dev-mem-restriction-patch-allow-reads.patch
dev-mem-restriction-patch.patch
enhanced-i-o-accounting-data-patch.patch
enhanced-memory-accounting-data-collection-tidy.patch
enhanced-memory-accounting-data-collection.patch
ide_arch_obsolete_init-fix.patch
idle-thread-preemption-fix.patch
invalidate_inode_pages-mmap-coherency-fix.patch
invalidate_inodes-speedup.patch
make-tree_lock-an-rwlock.patch
mm-higher-order-watermarks-fix.patch
mm-higher-order-watermarks.patch
mm-keep-count-of-free-areas.patch
mm-restore-atomic-buffer.patch
mm-teach-kswapd-about-higher-order-areas.patch
no-buddy-bitmap-patch-revisit-for-mm-page_allocc-fix.patch
no-buddy-bitmap-patch-revisit-for-mm-page_allocc.patch
no-buddy-bitmap-patch-revist-intro-and-includes.patch
provide-a-filesystem-specific-syncable-page-bit-fix-2.patch
provide-a-filesystem-specific-syncable-page-bit-fix.patch
provide-a-filesystem-specific-syncable-page-bit.patch
radix_tree_delete-fix.patch
readpage-vs-invalidate-fix.patch
requeue_granularity.patch
vm-routine-fixes.patch

ebuild - > http://www.munet.eu.org/~fallow/vv_e1/v ... -r1.ebuild
all dir -> http://www.munet.eu.org/~fallow/vv_e1/

greetings

[gun26]

Okay, I got this one compiled last night, emerging with USE="vesa_tng" and otherwise just doing a make oldconfig with my config from 2.6.10-rc1-vv_e2. I didn't need to do any patching of my own for nvidia - looks like you took care of that already. Seems to be stable and fast - nice job, again!

[fallow]

Okay, I got this one compiled last night, emerging with USE="vesa_tng" and otherwise just doing a make oldconfig with my config from 2.6.10-rc1-vv_e2. I didn't need to do any patching of my own for nvidia - looks like you took care of that already. Seems to be stable and fast - nice job, again!

thx , I see that You and I like partial mm fixes I think about return to the Staircase , but in my feelings O)1+mm fixes doing pretty well , Maybe You have some ideas , what to add also to next releases ? If You have some time , maybe You also do something as vivid ?

greetings

[darklegion]

Apt-get segaults with this kernel and then basically brings down my whole system and then requires a hard reboot.Does not happen with 2.6.9-cko3.It appears to be a bug in the reiser4 code,when I reboot into that kernel I will grab the output and post it back here.

[fallow]

ok- w8ing.
on my x86 - amd1.0 there are no problems with r4 (all partitions except /boot at now) .

greetings

[chickaroo]

ooooh nice kernel. i really think morton's kernel tree is a nice, but they do put too many experimental stuff in it. (i guess it's just a testground) i can see how much work you put into this with everything you have there. i couldn't even fix the hunks on vesa-tng when i tried to patch 2.6.10-rc2 my reiser4 port was a complete failure also... lol.
getting tired of ck based kernels anyways, i can't wait to give this a shot

EDIT: actually i think it was gensplash that i was trying to fix hunks on... two files were a mess, one of them being fbcon.c

EDIT2: wow i just noticed you did manage to get gensplash in here. way to go man! i praise you

[fallow]

nice chickaroo

I also like mm , but not with all stuff . partial mm is good solution imho
mm is good testground hehe , but many of mm patches are in vanilla now. so, why not to add a little more hehe

greetzz

[chickaroo]

LUFS was broken tho, i noticed an unknown symbol.

gonna see how well this kernel passes my Doom3 test on "ULTRA"

[chickaroo]

Nov 18 06:26:26 Selphie oom-killer: gfp_mask=0xd2
Nov 18 06:26:27 Selphie DMA per-cpu:
Nov 18 06:26:27 Selphie cpu 0 hot: low 2, high 6, batch 1
Nov 18 06:26:27 Selphie cpu 0 cold: low 0, high 2, batch 1
Nov 18 06:26:27 Selphie Normal per-cpu:
Nov 18 06:26:27 Selphie cpu 0 hot: low 32, high 96, batch 16
Nov 18 06:26:27 Selphie cpu 0 cold: low 0, high 32, batch 16
Nov 18 06:26:27 Selphie HighMem per-cpu: empty
Nov 18 06:26:27 Selphie
Nov 18 06:26:27 Selphie Free pages: 2864kB (0kB HighMem)
Nov 18 06:26:27 Selphie Active:87256 inactive:1609 dirty:0 writeback:0 unstable:0 free:716 slab:2815 mapped:87795 pagetables:442
Nov 18 06:26:27 Selphie DMA free:88kB min:88kB low:108kB high:132kB active:2584kB inactive:8kB present:16384kB pages_scanned:4676 all_unreclaimable? yes
Nov 18 06:26:27 Selphie protections[]: 0 0 0
Nov 18 06:26:27 Selphie Normal free:2776kB min:2804kB low:3504kB high:4204kB active:346440kB inactive:6428kB present:507840kB pages_scanned:461460 all_unreclaimable? yes
Nov 18 06:26:27 Selphie protections[]: 0 0 0
Nov 18 06:26:27 Selphie HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Nov 18 06:26:27 Selphie protections[]: 0 0 0
Nov 18 06:26:27 Selphie DMA: 0*4kB 1*8kB 1*16kB 0*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 88kB
Nov 18 06:26:27 Selphie Normal: 0*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2776kB
Nov 18 06:26:27 Selphie HighMem: empty
Nov 18 06:26:27 Selphie Swap cache: add 46370, delete 42871, find 2854/4038, race 0+0
Nov 18 06:26:27 Selphie Out of Memory: Killed process 15593 (doom.x86).


hmm... *scratches head* i have plenty of swap, and this never happens with the ck based kernels i've used recently. think this is something to do with dealine? or maybe the cpu schedular?

EDIT: happens everytime i try to load a new game, after abuot 3 minutes loading, my system kinda freezes for a bit and then it kills doom3.
(just for the record, i have a *relatively stable* OC'd 2.5GHz Athlon XP with 512MB dual channel ddr400 and 781MB swap) -- passes all stress tests i through at it

EDIT2: booted in 2.6.9-nitro4 right now (with ck3 staircase and cfq2) and it loads considerably faster, and no oom issues either.
i'll experiment with some of the other io schedulers in vivid if you think deadline could be causing some of this.

[fallow]

hm .
I don`t have experience with games , I don`t have any game on my linux box.
Nitro is ck based so have Con`s vm work , vivid in the past was based on ck also , but I decided to do O)1 cpu sched + partial mm fixes , without staircase since 2610rc.
wchich cpu scheduler is better is a long long story hehe
I prefer staircase and o)1.

I don`t have doom3 I can`t test it .Imho is quite possible that erros is in deadline side, but You can test it by switching io scheduler at runtime

We have also release based on 269 and ck with of other stuff patchlist -> http://forums.gentoo.org/viewtopic.php? ... 28#1767728

I think that erros can by generated by vm side...If you have time and If you will of course ,maybe reversing vm part helps.

I try to test vm side of this release ...

[chickaroo]

works great with cfq2

[fallow]

hmmm ok , You`re have right My new Guru

greetings

[chickaroo]

hmm
actually i spoke too soon. after writting that last post, i tried to switch back to my other console running doom and my screen froze lol. rebooted and fsck'd my reiser4 partitions (getting errors like always of course) and tried to load doom again. oom... must be something in the vm that isn't managing memory too well.

could be 2.6.10-rc2 or some of the mm patches, althuogh that's kind of unlikely since you only mainly included the fixes

[fallow]

hm, ok , i do some patch to this release - maybe reverse vm mm part and add Con`s vm work ?

greetings

[fallow]

ok , patch for vm alternative -> http://www.munet.eu.org/~fallow/vv_e1/vm_alt1.diff.bz2

this patch reversing mm`s vm fixes (mm* and vm*) , and provides Con`s

Code: Select all

increase_prio0_scanning.diff
mwII.diff

usage of course in vv_e1 dir

Code: Select all

# bzip2 -dc vm_alt1.diff.bz2 | patch -p1 

greetings

[bollucks]

Nov 18 06:26:26 Selphie oom-killer: gfp_mask=0xd2

2.6.9 mainline has an oom-killer problem. It isn't specific to any sources.

[darklegion]

OK,the segmentation fault does not seem to be happening anymore since I booted into cko3.It now works correctly in both 2.6.10-rc2-mm2 and your kernel.And now that I remember right I did actually save the output when it happened but because of the hard lock the journal did not save it apparently and so I lost the information.I believe it is just in a bug in your kernel(or one of the patches you are using) as I don't seem to remember it happening in the 2.6.10-rc2-vanilla.Too bad I can't reproduce it now

[chickaroo]

2.6.9 mainline has an oom-killer problem. It isn't specific to any sources.

i've never encounted this problem using any of the 2.6.9 kernels (ck, cko, nitro, love), and i've been using 2.6.9 since rc2.

ok , patch for vm alternative -> http://www.munet.eu.org/~fallow/vv_e1/vm_alt1.diff.bz2

this patch reversing mm`s vm fixes (mm* and vm*) , and provides Con`s

Code: Select all

increase_prio0_scanning.diff
mwII.diff

usage of course in vv_e1 dir

Code: Select all

# bzip2 -dc vm_alt1.diff.bz2 | patch -p1 

greetings

great i can't wait to try it

[chickaroo]

still getting those OOM messages. it must be the 2.6.10 kernel that still has some bugs.

that 2.6.9 vivid wouldn't startx with nvidia properly, system froze. maybe i'll try it again though., i could have had something wrong

[fallow]

hm, nobody said that is something wrong with vivid 269 and nvidia (working for me and troll (troll doing this line of vivid) so maybe something behind Your side )

maybe it`s some bug in 2610rc2 but , I`m going to do some new release ( today or tommorow ) , so I will select patches for vm* and mm* more carefully ( maybe none vm* and mm* patch from mm tree) and add Con`s vm from CK as standard.

in addition (imo) to stay with O)1 Scheduler is a good idea

greetings

[chickaroo]

hmm, maybe the newer kernel is just more sensitive to memory intensive applications. (doom3 sucks the life out of my box lol) i stuck another stick of 256MB DDR400 and it runs beautifully now with vve1 + alternate vm. (768MB total mem now)

i'm gonna try out the original with the O)1 schedular soon

[chickaroo]

O)1 passes the doom3 test

[chickaroo]

working really well... very stable. think you can fix this in the next release?

Code: Select all

WARNING: /lib/modules/2.6.10-rc2-vve1/kernel/fs/lufs/lufs.ko needs unknown symbol kill_proc_info

[fallow]

ok 1/2 done I will fix it also tomorrow

greetings