June 2009

よく分からんが、僕のパッチが世界のどこかのAndroidのビルドを壊したらしい。
そんな報告いらないよ


From: davidb@xxxxx.com
To: 革命の日々さん
Date: Thu, 25 Jun 2009 14:55:42 -0700
Subject: Re: kernel build change 3229 patch 1 success
----

On Thu, Jun 25, 2009 at 02:43:39PM -0700, davidb@xxxxx.com wrote:
> - fetching
> From git://git-android.quicinc.com/kernel/msm
> * [new branch] refs/changes/25/3225/1 -> refs/changes/25/3225/1

Sorry about the spam. I just discovered, the hard way, that our
auto-builder sends the results to the author and not the
committer of the patch. This is fixed now.

David Brown



追記: うっかり本名がバレてしまう内容を含んでいたので削除した

vnetとかvirbrの意味が分からずにしばらく、とまどったが分かってしまえば簡単。
開発に使うという要件から、外からsshでつなぐことが出きるのは必須。
よってbridge型接続を考える。

まず、ホストのeth0をブリッジに関連付ける

/etc/sysconfig/network-script/ifcfg-eth0


# Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express
DEVICE=eth0
BRIDGE=virbr0
#BOOTPROTO=none

HWADDR=00:22:19:1e:00:71
ONBOOT=yes
IPADDR=192.168.1.220
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no
TYPE=Ethernet
NETMASK=255.255.255.0
GATEWAY=192.168.1.5


太字のように、BRIDGE行でvirbr0に関連付け、BOOTPROTOをコメントアウト

次にvirbr0の設定ファイルを作る

/etc/sysconfig/network-script/ifcfg-virbr0

DEVICE=virbr0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge



ネットワークをリスタート


# service network restart



virt-managerで新しいネットワークデバイスを追加
virtbr0ブリッジの新しいデバイスを作る。

終わり

参考:
KVM HOWTO - netowrking http://www.linux-kvm.org/page/Networking

/etc/security/limits.conf に


#
#

* soft nproc 100000


と書いたら、以下のような結果に。
どこかに上限があるっぽいのだが、規則がよく分からん。
55296 って中途半端じゃね?



% ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 10240
-c: core file size (blocks) 0
-m: resident set size (kbytes) unlimited
-u: processes 55296
-n: file descriptors 1024
-l: locked-in-memory size (kb) 32
-v: address space (kb) unlimited
-x: file locks unlimited
-i: pending signals 55296
-q: bytes in POSIX msg queues 819200
-e: max nice 0
-r: max rt priority 0

ほぼT/O。
最近、LKML的義理人情の兼ね合いでFreeBSDをインスコしたのだけれど、なぜか/ パーティションのみSoftUpdate がOFFがインストーラのデフォルトの模様
OFFにするメリットが思いつかないので、誰か教えてください。

ところで、SoftUpdateって、NCQとかが、OSの知らないところで、I/Oの順番入れ替えたらアウトのような気がするが、I/O barrier の実装ってどうなってんの?

本家Slashdotより

http://linux.slashdot.org/story/09/06/10/1243232/Linux-Kernel-2630-Released

Can anyone explain to me why Linux has so many filesystems? Windows has had NTFS for years (admittedly, several versions, but never any compatibility issues that I've come across), and Linux has, what, 73 or something?! Is it really that hard to get it right?



なんで、こんなにいっぱいファイルシステムが必要なの?と質問

Can anyone explain to me why Ford has so many kinds of cars? Tesla has had a 2 seat roadster for years (admittedly, several versions, but never any compatibility issues that I've come across), and Ford has, what, 73 or something?! Is it really that hard to get it right?



なんで、フォードはこんなに色々な車を作ってるの?と揶揄


お馬鹿トークだよなー

Shinh先生に繰り返し要望されていたスレッドに名前をつける機能だが、実はすでに実装済みだったらしい。

prctl(PR_SET_NAME) するだけ。
アルェーーー



Date: Tue, 16 Jun 2009 21:14:26 +0200
From: Bert Wesarg
To: Stefani Seibold
Cc: linux-kernel , linux-mm , Andrew Morton
Subject: Re: [RFC] set the thread name


Hi,

On Tue, Jun 16, 2009 at 20:39, Stefani Seibold wrote:
> Currently it is not easy to identify a thread in linux, because there is
> no thread name like in some other OS.
>
> If there were are thread name then we could extend a kernel segv message
> and the /proc//task//... entries by a TName value like this:
prctl(PR_SET_NAME, ...) works perfectly here.

Bert

/* -*- c -*- */

#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include

void *
thread(void *arg)
{
unsigned long i = (unsigned long)arg;
char comm[16];
snprintf(comm, sizeof comm, "task %02lu", i);
prctl(PR_SET_NAME, comm, 0l, 0l, 0l);

sleep(10);

return NULL;
}

int
main(int ac, char *av[])
{
pthread_t thr;
unsigned long i, n = 10;
char comm[16];

printf("%u\n", getpid());
sleep(5);
snprintf(comm, sizeof comm, "master");
prctl(PR_SET_NAME, comm, 0l, 0l, 0l);
sleep(5);

for (i = 0; i < n; i++)
pthread_create(&thr, NULL, thread, (void *)i);

pthread_join(thr, NULL);

return 0;
}

>
> Greetings,
> Stefani

コミットログから転載

Change mutex contention behaviour such that it will sometimes busy wait on
acquisition - moving its behaviour closer to that of spinlocks.

This concept got ported to mainline from the -rt tree, where it was originally
implemented for rtmutexes by Steven Rostedt, based on work by Gregory Haskins.

Testing with Ingo's test-mutex application (http://lkml.org/lkml/2006/1/8/50)
gave a 345% boost for VFS scalability on my testbox:

# ./test-mutex-shm V 16 10 | grep "^avg ops"
avg ops/sec: 296604

# ./test-mutex-shm V 16 10 | grep "^avg ops"
avg ops/sec: 85870

The key criteria for the busy wait is that the lock owner has to be running on
a (different) cpu. The idea is that as long as the owner is running, there is a
fair chance it'll release the lock soon, and thus we'll be better off spinning
instead of blocking/scheduling.

Since regular mutexes (as opposed to rtmutexes) do not atomically track the
owner, we add the owner in a non-atomic fashion and deal with the races in
the slowpath.

Furthermore, to ease the testing of the performance impact of this new code,
there is means to disable this behaviour runtime (without having to reboot
the system), when scheduler debugging is enabled (CONFIG_SCHED_DEBUG=y),
by issuing the following command:

# echo NO_OWNER_SPIN > /debug/sched_features

This command re-enables spinning again (this is also the default):

# echo OWNER_SPIN > /debug/sched_features


sysfs経由でclocksourceを手動で変えられるらしい


# pwd
/sys/devices/system/clocksource/clocksource0

# ls
available_clocksource current_clocksource

# cat available_clocksource
tsc hpet acpi_pm jiffies

# cat current_clocksource
tsc

# echo hpet > current_clocksource

# cat current_clocksource
hpet


↑このページのトップヘ