http://cpplover.blogspot.com/2009/10/crackedcomreview-of-windows-7.html

なにこれ。面白すぎる

なんか、DreamCastの巻き添えを食らってandroidのコードが全削除食らったようだ。
何この面白展開

On Mon, Oct 05, 2009 at 04:21:35PM -0700, Randy Dunlap wrote:

> On Mon, 5 Oct 2009 19:03:24 +1100 Stephen Rothwell wrote:

> 

> > Hi all,

> > 

> > Changes since 20091002:

> 

> 

> drivers/staging/dream/gpio_axis.c:18:30: error: linux/gpio_event.h: No such file or directory



Argh, I'm getting sick of the dream code.  I'll sit down tomorrow and

work it all out, _or_ just delete the tree.



I just deleted drivers/staging/android/ so getting dream support seems a

bit far off :(

DreamCastの開発を今更やっているのも、その巻き沿いでAndroidがアボーンされるのもネタとして面白すぎる

追記：typoを修正。DreadCastになってた

追記２： Paulからツッコミ。dreamディレクトリは欧米向けの携帯電話らしい。失礼。

追記３： このdropの直接的な原因は、長期のビルドエラー放置なんだけど、ビルドエラーの直接の原因は僕がDavidのOOMパッチをRevertしたときのrevert漏れだった。ははは、android関係者すまん。もし、もう一度mainlineを狙うなら協力せんでもないっすよ。

追記４： なんか、一部で誤解を招いているようなのでさらに補足。というか自己弁護。僕は一ヶ月以上前に修正パッチを投稿しているので、無視し続けた android 関係者が一番悪いんです。

定期的に現れるext4は遅いスレッド。今回はReiser3から移行したらカーネルコンパイルが
遅くなったというもの

Hello,



I'm considering replacing Reiser3 filesystem with some newer one.

I ran compilebench benchmark. Read performance is lower with ext4.

Is it expected or is it possible to fix it?



Ext4:

read tree total runs 11 avg 20.47 MB/s (user 0.53s sys 0.74s)

read compiled tree total runs 4 avg 32.94 MB/s (user 0.61s sys 1.17s)



Reiser3:

read tree total runs 11 avg 26.33 MB/s (user 0.54s sys 0.81s)

read compiled tree total runs 4 avg 41.82 MB/s (user 0.62s sys 1.36s)



RAID details:



md8 : active raid10 sda7[0] sdd7[3] sdc7[2] sdb7[1]

      62925824 blocks 256K chunks 2 far-copies [4/4] [UUUU]



Ext4:

mkfs.ext4 -E stride=64,stripe-width=128 /dev/md8

mount -t ext4 -o noatime,auto_da_alloc,commit=600 /dev/md8 /mnt/md8



Reiser3:

mount -t reiserfs /dev/md8 /mnt/md8

mount -t reiserfs -o noatime,notail /dev/md8 /dev/md8



Ext4 results:

intial create total runs 10 avg 172.76 MB/s (user 0.43s sys 0.60s)

create total runs 14 avg 36.49 MB/s (user 0.42s sys 0.59s)

patch total runs 15 avg 15.16 MB/s (user 0.24s sys 0.49s)

compile total runs 14 avg 64.07 MB/s (user 0.10s sys 0.59s)

clean total runs 10 avg 393.43 MB/s (user 0.02s sys 0.06s)

read tree total runs 11 avg 20.47 MB/s (user 0.53s sys 0.74s)

read compiled tree total runs 4 avg 32.94 MB/s (user 0.61s sys 1.17s)

delete tree total runs 10 avg 2.51 seconds (user 0.24s sys 0.42s)

delete compiled tree total runs 4 avg 2.63 seconds (user 0.28s sys 0.50s)

stat tree total runs 11 avg 1.99 seconds (user 0.23s sys 0.18s)

stat compiled tree total runs 7 avg 2.11 seconds (user 0.27s sys 0.21s)



Reiser3 results:

intial create total runs 10 avg 82.74 MB/s (user 0.45s sys 1.13s)

create total runs 14 avg 28.54 MB/s (user 0.45s sys 1.19s)

patch total runs 15 avg 10.91 MB/s (user 0.24s sys 0.86s)

compile total runs 14 avg 47.49 MB/s (user 0.10s sys 1.27s)

clean total runs 10 avg 270.21 MB/s (user 0.02s sys 0.15s)

read tree total runs 11 avg 26.33 MB/s (user 0.54s sys 0.81s)

read compiled tree total runs 4 avg 41.82 MB/s (user 0.62s sys 1.36s)

delete tree total runs 10 avg 3.38 seconds (user 0.24s sys 0.72s)

delete compiled tree total runs 4 avg 4.14 seconds (user 0.27s sys 0.88s)

stat tree total runs 11 avg 2.09 seconds (user 0.22s sys 0.18s)

stat compiled tree total runs 7 avg 2.27 seconds (user 0.25s sys 0.21s)

--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/

creating tar of compiled kernel takes much longer with ext4



time tar c linux-2.6.31 | cat >/dev/null



reiser3:

real    0m11.425s

user    0m0.229s

sys     0m1.586s



ext4:

real    0m23.942s

user    0m0.183s

sys     0m1.440s



partition was remounted before test

これに対するTedの回答。
dir_indexをOFFにしたら速くなると思うよ。ext4の改善はない。

You didn't say which version of the kernel you are using, which could

be important when asking these sorts of questions about potential

performance problems.



However, in this case, I suspect the issue is the nature of how

compilebench is structured.  Compilebench does the following which

makes it work particularly well for filesystems like reiserfs and

btrfs, and not so much for ext3 and ext4.  Quoting from the

compilebench web page:



   compilebench starts by putting these lists of file names into an

   order native to the filesystem it is working on. The files are

   created in sorted order based on the filename, and then readdir is

   used to find the order the filesystem uses for storing the

   names. After this initial phase, the filesystem native order is

   used for creates, patches and compile. Deleting, reading and

   stating the trees are done in readdir order.



The key here is that it reads the tree in readdir order.  Normally,

when you compile a kernel, the order in which you read and write files

is controlled by the Makefile; you don't get to read and write the

files in the order which just happens to be the most convenient for

the file system's b-tree hash algorithm.



Now, there are some workloads which compilebench might accurately

model --- for example, tar'ing up a directory.  However, despite the

name of the benchmark, it doesn't accurately model a kernel compile.



If you only care about compilebench numbers, you can try creating the

file system with the dir_index feature disabled.  This is the feature

that speeds up random access to directories; unfortunately, it means

that when you read files in readdir order, it causes extra random

reads to th einode table.  However, if your real-life workload is one

where file reads are always magically in readdir order, dir_index adds

overhead without adding any benefit.   



The bottom line is that I'm not terribly worried about trying to

improve ext4's performance on compilebench, since I don't believe it's

a benchmark that models realistic real-life workloads.



Regards,



						- Ted

VMwareの連中が、伝統的なVMIを使ったパラバーチャライゼーションより、EPT/NPTを使ったほうが速いのが分かったので、VMIは近々削除するよ。とのこと

おいおい、つい最近までVMwareのコード書き換え技術はァァァァァァ、世界イチィィィィィィ
URYYYYYYYYYYYYYY

とかいってたじゃんか。

Hi,



We ran a few experiments to compare performance of VMware's

paravirtualization technique (VMI) and hardware MMU technologies (HWMMU)

on VMware's hypervisor.



To give some background, VMI is VMware's paravirtualization

specification which tries to optimize CPU and MMU operations of the

guest operating system. For more information take a look at this

http://www.vmware.com/interfaces/paravirtualization.html



In most of the benchmarks, EPT/NPT (hwmmu) technologies are at par or

provide better performance compared to VMI.

The experiments included comparing performance across various micro and

real world like benchmarks.



Host configuration used for testing.

* Dell PowerEdge 2970

* 2 x quad-core AMD Opteron 2384 2.7GHz (Shanghai C2), RVI capable.

* 8 GB (4 x 2GB) memory, NUMA enabled

* 2 x 300GB RAID 0 storage

* 2 x embedded 1Gb NICs (Braodcom NetXtreme II BCM5708 1000Base-T)

* Running developement build of ESX.



The guest VM was a SLES 10 SP2 based VM for both the VMI and non-VMI

case. kernel version: 2.6.16.60-0.37_f594963d-vmipae.



Below is a short summary of performance results between HWMMU and VMI.

These results are averaged over 9 runs. The memory was sized at 512MB

per VCPU in all experiments.

For the ratio results comparing hwmmu technologies to vmi, higher than 1

means hwmmu is better than vmi.



compile workloads - 4-way : 1.02, i.e. about 2% better.

compile workloads - 8-way : 1.14, i,e. 14% better.

oracle swingbench - 4-way (small pages) : 1.34, i.e. 34% better.

oracle swingbench - 4-way (large pages) : 1.03, i.e. 3% better.

specjbb (large pages)   : 0.99, i.e. 1% degradation.



Please note that specjbb is the worst case benchmark for hwmmu, due to

the higher TLB miss latency, so it's a good result that the worst case

benchmark has a degradation of only 1%.



VMware expects that these hardware virtualization features will be

ubiquitous by 2011.



Apart from the performance benefit, VMI was important for Linux on

VMware's platform, from timekeeping point of view, but with the tickless

kernels and TSC improvements that were done for the mainline tree, we

think VMI has outlived those requirements too.



In light of these results and availability of such hardware, we have

decided to stop supporting VMI in our future products.



Given this new development, I wanted to discuss how should we go about

retiring the VMI code from mainline Linux, i.e. the vmi_32.c and

vmiclock_32.c bits.



One of the options that I am contemplating is to drop the code from the

tip tree in this release cycle, and given that this should be a low risk

change we can remove it from Linus's tree later in the merge cycle.



Let me know your views on this or if you think we should do this some

other way.



Thanks,

Alok





--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/

最後のユーザがいなくなったとの理由で、markerが削除されました。
しかし、out of treeにSystemTapというビッグユーザーがいるんだが。。。

まあ、Christoph Hellwig や Ingo MolnarにSystemTapの事を話しても無駄である。
コミュニティ活動をしないFrankが悪い

Gregがしばらく前に2.6.32でのstagingの状況を報告してた。
これによると、かなり多くのドライバが作業が止まっているらしい。

android はいまだに2.6.29で作業してる。とかMicrosoftのHyper-V担当者が消えちゃったとか
面白い事が色々書いてある

まあ、ドライバ以外全部dropしてほしいね。正直

Hi all,



Here's a summary of the state of the drivers/staging/ tree, basically

what will be coming in the 2.6.32 merge, and what the status of the

different drivers are so far.



First off, drivers/staging/ is NOT a dumping ground for dead code.  If

no one steps up to maintain and work to get the code merged into the

main portion of the kernel, the drivers will be removed.



As proof of that, the EPL (Ethernet Power Link) driver will be removed

in the .32 kernel, as no one is working on it, the upstream developers

never respond to my emails, and no one seems to care about it.



The pata_rdc driver is also going to be removed, as there is a "better"

one being merged through the libata tree for this hardware.



So, taking the drivers in chunks, here's some that have had active

development on for the .32 release:

	- rt* wireless drivers.  Bart has done amazing work merging all

	  of these together into something much better than they

	  originally were.  And even better, they still work!   Great

	  job Bart!



	- rtl* wireless drivers.  Again, Bart has been doing great work

	  here.



	- wlan-ng driver: a bit of work here, but this seems to be

	  dropping off, with the loss of a test platform for the driver.

	  Hopefully someone has a device around and can help out here.



	- comedi drivers had only a bit of work done, lots more is

	  needed here, let's not loose the fact that this is getting

	  closer to a mergable shape.



	- Android drivers have had a bit of work done, but upstream

	  seems to not care at all about what is going on here, as they

	  are working to forward port their code to the 2.6.29! kernel.

	  {sigh}.  If this keeps up, the drivers will be dropped in the

	  2.6.32 kernel release.

	  Note, Pavel has been adding some of the Dream hardware

	  drivers, which are separate from the core Android drivers.  I

	  have no objection to those, but they should work to get merged

	  to their "correct" places in the tree in another release or

	  so.



	- w35und driver.  It's slowly being worked on.



	- echo driver.  This one is now in good enough shape to merge

	  into the main kernel tree.  I'll send out review patches soon

	  for this.



	- eth131x driver. Alan Cox is working on fixing up the issues in

	  this driver.  Hopefully it will get into mergable shape soon.



New drivers that will show up in the .32 kernel release:

	- vt66* wireless drivers.  These VIA drivers are being actively

	  worked on to get into a much better shape.  Nice job.



	- new rt3090, and rtl8192e wireless drivers have been added and

	  worked on cleaning up issues involved in them.



	- Microsoft Hyper-V drivers.  Over 200 patches make up the

	  massive cleanup effort needed to just get this code into a

	  semi-sane kernel coding style (someone owes me a bit bottle of

	  rum for that work!)  Unfortunately the Microsoft developers

	  seem to have disappeared, and no one is answering my emails.

	  If they do not show back up to claim this driver soon, it will

	  be removed in the 2.6.33 release.  So sad...



	- quatech_usb2 driver.  I don't know if it quite works, but

	  someone is developing it, so I'm not complaining :)



	- VME bus drivers.  Yeah!  They are progressing nicely.



	- SEP and RAR drivers.  Alan Cox has been working on cleaning

	  these up a lot.



	- IIO (Industrial I/O), these are new drivers that are being

	  actively worked on.



	- pohmelfs and dst.  It seems that DST is dead, so I think I

	  will remove it in .33.  pohmelfs is under active development

	  outside of the tree, and hopefully patches start moving in

	  here to help out with keeping it up to date.



	- cowloop.  Yes, another COW driver!  :)  Seriously, this does

	  things that DM can't do, so it might be useful.  The upstream

	  developer is interested in getting this merged properly, and

	  is working on cleaning it up.



Drivers not being actively worked on:

	- otus.  This is sitting here until a "real" wireless driver

	  will be merged through the wireless tree.  Hopefully that

	  happens soon.



	- agnx wireless driver.  No one seems to care about it.  If no

	  one steps up soon, it will be removed in .33.



	- altpciechdma.  Upstream developers seem to have disappeared.

	  Again, if no one steps up, it will be removed in .33



	- asus_oled.  This only needs minor cleanups to get merged

	  properly into the main tree.  If someone wants an easy

	  project, this would be it.



	- at76_usb wireless driver.  Again, no one working on it, it

	  will be dropped in .33.



	- b3dfg.  I really do not think anyone cares about this.  again,

	  will be dropped if this is true in .33.



	- cpc-usb.  After the initial flurry of development, everyone

	  seems to have run away.  Was it the fact that I hadn't

	  showered in a few days?  Again, will be removed if no one

	  comes back.  And I am wearing deodorant now...



	- frontier.  A nice driver, again, should not be hard to get

	  merged into the main tree, if someone wants an easy project...



	- go7007.  Ugh.  Unless someone steps up now to take this over,

	  it's going to be removed in .33.  There is no hardware made

	  with this anymore, and no specs around that I know of, and the

	  code isn't the nicest in the world.



	- heci.  A wonderful example of a company throwing code over the

	  wall, watching it get rejected, and then running away as fast

	  as possible, all the while yelling over their shoulder, "it's

	  required on all new systems, you will love it!"  We don't, it

	  sucks, either fix it up, or I am removing it.



	- line6.  Another nice driver that should be simple to get

	  merged.  Please, if you are looking for something to do, this

	  is it.



	- me4000 and meilhaus.  They work on the same hardware, and they

	  duplicate the existing COMEDI drivers.  Someone thinks that

	  custom userspace interfaces are fun and required.  Turns out

	  that being special and unique is not what to do here, use the

	  COMEDI drivers instead.  These will be removed.  Heck, I'll go

	  remove them for .32, there is no reason these should still be

	  around, except to watch the RT guys squirm as they try to

	  figure out the byzantine locking and build logic here (which

	  certainly does count for something, cheap entertainment is

	  always good.)



	- mimio.  Another driver that should be simple to get merged.

	  Someone just step up to do this please, there are users of

	  this hardware out there.



	- p9auth.  While it seemed like a good idea, I don't think that

	  anyone actually uses this.  It will be removed in .33 unless

	  someone comes forward.



	- panel.  Another one that should be simple to merge.  Anyone?



	- phison.  What?  I thought I asked for this to be merged a

	  while ago, sorry about that, no reason it should still be in

	  staging anymore, it's just so small it slipped through the

	  cracks...



	- poch.  A long-suffering company is enduring the slowest

	  developers in the world here.  Hopefully the code will be

	  replaced with a UIO driver, but testing the userspace side

	  seems to be difficult and slow.  I have to give Redrapids

	  major credit for being patient here, they are being amazing.



	- rspiusb.  A weird, very expensive camera, from a company that

	  does not want to release the specs, and wants custom userspace

	  interfaces.  The code hasn't built since the 2.6.20 days.

	  I'll go delete it now from .32, it doesn't deserve to live as

	  no one cares about it, least of all, the original authors of

	  the code :(



	- slicoss and sxg.  These are being developed by a consulting

	  company for the main producer of the chips.  Yet they seem to

	  have disappeared half-way through the job.  Odd.  Hopefully

	  they come back soon.



	- stlc45xx.  Another wireless driver that no one seems to care

	  about.  So sad.  I guess no one will miss it when it goes away

	  in .33.



	- udlfb.  Video over USB, it doesn't get anymore whacked than

	  that.  This is still being developed but the developer doesn't

	  like to do incremental updates for some odd reason.  Hopefully

	  he pops up again with an update.  But for now, it is quite

	  workable for a number of developers.



	- usbip.  USB over IP.  I guess if you ran video over IP to your

	  USB device, that would be more whacked than just video over

	  USB.  This did get one big update during the .32 development

	  cycle, hopefully the developer can come back again when they

	  get some free time to continue working on it.  Rumor has it

	  that some major distros are starting to rely on this code, so

	  it would be nice to get their help to get it working better...



That should cover all of the 600+ patches in the staging tree for the

.32 kernel merge, and the existing drivers/staging/ tree.  If I missed

anything, please let me know.



Any questions?



thanks for making it this far,



greg k-h

--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/

http://lttng.org/?q=node/18

また奇特な

なんか、住宅販売のチラシが家に投げ込まれてた、見るともなく見ていると、・・ええ！４千万！！
誰が買うんだ、こんなの？

50坪、駅３分の価値を思い知った。