zz from http://www.thegibson.org/blog/archives/305
My personal take away from this blog:
1. Getting a faculty job in a decent university is reallllllllly hard. 2 OSDI, 3 SOSP and other publications on FAST?!?! It is hard to imagine myself making this kind of achievement in 5 years, even though I am lucky enough to work with his former advisor. (Would it be easier for research labs affilicated to companies? But you woundn't have grad students for most time of a year, and that's like a whole different ecosystem).
2. Publishing in top system conferences is kind of subjective (at least to me). You have to guess what will make PC interested, and it is still a bit mysterious to me :(
My advisor seems to have a quite different perspective on what is interesting work in the system area than I do; and I guess I should try to develop this kind of perspective too if I am seriously thinking about research as my career. (Still can not believe some debugging linux stuff get their way into OSDI, though...)
3. Congrats to Haryadi! This is like the first faculty in our group? Even though those guys in Microsoft research or national labs are also active in publishing papers (Eurosys, SIGOPS etc.), but I guess being in an university is different.
===========================================================================
I follow Ed Felten’s blog, Freedom To Tinker (which is actually now a blog for many people at Princeton’s Center for Information Technology Policy) — it has good coverage on issues like electronic voting and intellectual property. Dan Wallach, a well known security (among other things) researcher at Rice, published an interesting post titled “Acceptance rates at security conferences” assessing the state of academic CS conferences in the area of security. He points out that the conferences are getting increasingly competitive with an ever growing field of researchers and a relatively fixed number of conference venues; he notes that this will lead to certain “structural problems” in the research community and discusses potential options.
He also points to Matt Welsh‘s thoughts on similar issues in the systems community:
“Scaling up conferences”
“Scaling up program committees”
This is of particular interest to me since, as a PhD student, I am an academic systems researcher. Dan Wallach summarizes Matt first post as follows:
He argues that there’s a real disparity between the top programs / labs and everybody else and that it’s worthwhile to take steps to fix this. (I’ll argue that security conferences don’t seem to have this particular problem.) He also points out what I think is the deeper problem, which is that hotshot grad students must get themselves a long list of publications to have a crack at a decent faculty job. This was emphatically not the case ten years ago.
I definitely see what Matt is talking about in the systems community. For example, for a large subset of lower-level systems work*, SOSP and OSDI are a sort of gold standard in publication venues. Each conference is held every two years (alternating years between the two venues), so each year 20-30 papers will be accepted total (for reference, OSDI ’08 accepted 26/193 and SOSP ’07 accepted 25/131). Given the size of the systems community, that doesn’t give much leeway for up-and-coming researchers, but a publication in such a venue is virtually required to be competitive academically — as Matt describes it, a publication in these venues is “a highly prized commodity, and one that is becoming increasingly valued over time.” Matt says:
Several of us on the hiring committee were amazed at how many freshly-minted Ph.D.s were coming out with multiple papers in places like SOSP, OSDI, and NSDI. Clearly there is a lot more weight placed on getting those papers accepted than there used to be. … Somewhere along the way the ante has been upped considerably.
I notice this too. For example, Georgia Tech’s College of Computing (where I am finishing my PhD) was ranked in the top 10 graduate programs in CS (#9) by US News and World Report in 2008. For systems research specifically, we were also ranked in US News and World Report’s top 10 (#10) in 2008. Now, of course US News and World Report’s rankings are contentious and reducing the work of a whole bunch of different researchers in CS to a single dimensional ordinal representing the whole program is very subjective, but the point is only to say that our program can be considered competitive in the universe of CS graduate programs.
But if you look at our publishing track record in these two prized venues, we’re virtually unrepresented. If you look at the OSDI proceedings, you will see that a paper from Georgia Tech has never been accepted there (my 2008 submission was rejected, although it did get decently positive reviews), and we have two SOSP papers — one in 97 which was collaborative with Microsoft Research and involved only students and no Georgia Tech faculty (which makes me wonder if it was related to an internship) and one in 2007 which was a collaboration between a student in the Electrical and Computer Engineering and a professor in the College of Computing. Compare this college-wide record with that of Haryadi Gunawi, an excellent faculty candidate interviewing at Georgia Tech this year. In his career as a PhD student, he had 2 OSDI and 3 SOSP publications (plus publications in top venues in other areas, like PLDI, ISCA and FAST). As a student, he has amassed significantly more publications in these prized venues than our whole College of Computing can claim**. And other students from his advisor(s) have similarly impressive CVs. Look at the students of many other “rockstar” systems researchers and you’ll see the same pattern; we had a parade of great faculty candidates with similarly strong records.
So what am I supposed to make of this? I get a deep sense of cynicism when I see trends like this over many years. Matt says, “I don’t have hard data to back this up, but it feels that it is increasingly rare to see papers from anything other than ‘top ten’ universities and labs in the top venues.” I would go a step further and say that there’s a certain “clique” (or “cabal” if you want something sinister) of key researchers who facilitate virtually all of the publications in these venues. If you are a student of one of these researchers, or a nth-generation student (e.g. a student of a faculty member who once was a student of…), you know how to do work that appeals to the program committee and present it in the proper way — if you don’t have the right perspective on these fine points of taste, your chances are grim.*** As a student, if your advisor is a big name, you can have a paper in these top venues every year. If you don’t, you have very bleak academic job prospects. Now I’m definitely not trying to diminish Haryadi’s impressive accomplishments, and his research is very exciting. But I get the sense that there’s a very strong dis-proportionality in academic publishing in systems that is a lot worse than most other areas in computer science.
A comment to Matt’s first post and the end of Dan’s post also pointed me to another relevant article. In May’s CACM Viewpoints, Ken Birman and Fred Schneider wrote an interesting critique of the state of systems conferences titled “Program Committee Overload in Systems” (here’s a free pdf from Fred Schneider — the same content but without the fancy formatting of the CACM hardcopy). This CACM article seems like a follow-up and expansion of an earlier work of Ken’s I’ve blogged about (titled “Overcoming Challenges of Maturity”).
Anyway, I’m glad that some well-respected systems researchers are being vocal about these issues. It’s definitely good to know I’m not the only one with gripes; I’ve been somewhat cynical about this for a while, but since I have very little clout it helps to find a few senior systems researchers with some common concerns.
* Yes, I understand that “lower-level” is a matter of perspective. To my electrical and computer engineering colleagues, things like hypervisors and operating systems count as “high-level” “end-user” programming.
** If you look at DBLP, you will find a good bit more from current College of Computing faculty, but I’m counting publications where the author is at Georgia Tech when the publication is made (i.e. the author’s affiliation at the time of the publication).
*** Even presented well, good work on certain kinds of systems topics just doesn’t seem to be interesting to the PCs of these top conferences (the Europeans have been irked by this for years — leading to the establishment of EuroSys).
2011年3月10日星期四
2010年11月28日星期日
linux software raid5 code reading notes (2)
A typical write process
1. When the bio corresponding to the write request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() will call handle_stripe_dirtying5().
6. Handle_stripe_dirtying5() will first check whether a reconstruct-write or a read-modify-write is more preferable according to how many extra data needs to be read. Then it will make the R5_LOCKED and R5_Wantread flag for the disk buffer that needs to be read if this stripe is PREREAD_ACTIVE. (The PREREAD_ACTIVE flag is marked subject to the delay policy of raid5 described elsewhere). Handle_stripe_dirtying5() then returned w/ STRIPE_HANDLE flag cleared for the current stripe.
7. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit the read I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
8. Release_stripe() is called to clear the PREREAD_ACTIVE request. In the meantime, Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Again, with STRIPE_HANDLE flag, the handle_stripe5() function will be called. It calls into handle_stripe_dirtying5(), which in turn directly calls schedule_reconstruction() since all the disk buffers are uptodate.
10. Schedule_reconstruction() will mark STRIPE_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT flag and R5_Wantdraian flag and set sh->reconstruct_state=reconstruct_state_drain_run for reconstruction write; or it will mark STRIPE_OP_PREXOR and STRIP_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT and R5_Wantdrain flags for read-modify-write. It will also lock appropriate buffers.
11. Raid5_run_ops() is called. For read-modiry-writes, it calls ops_run_prexor() to calculate the xor results for old data and old parity block. Then ops_run_biodrain() is called (for both rcw and rmw) to copy data from bio to per-disk-cache. Finally ops_run_reconstruct5() is called, which calculates the parity block contents.
12. Ops_run_io() is called to register I/O completion function to be raid5_end_write_request() and submit I/O request for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
13. Upon I/O completion, raid5_end_write_request() will clear R5_LOCKED flag and set STRIPE_HANDLE flag.
14. Again handle_stripe() is called, this time it does nothing but clear the STRIPE_HANDLE flag.
15. Control returns to make_request, which return the user-submitted bio.
1. When the bio corresponding to the write request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() will call handle_stripe_dirtying5().
6. Handle_stripe_dirtying5() will first check whether a reconstruct-write or a read-modify-write is more preferable according to how many extra data needs to be read. Then it will make the R5_LOCKED and R5_Wantread flag for the disk buffer that needs to be read if this stripe is PREREAD_ACTIVE. (The PREREAD_ACTIVE flag is marked subject to the delay policy of raid5 described elsewhere). Handle_stripe_dirtying5() then returned w/ STRIPE_HANDLE flag cleared for the current stripe.
7. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit the read I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
8. Release_stripe() is called to clear the PREREAD_ACTIVE request. In the meantime, Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Again, with STRIPE_HANDLE flag, the handle_stripe5() function will be called. It calls into handle_stripe_dirtying5(), which in turn directly calls schedule_reconstruction() since all the disk buffers are uptodate.
10. Schedule_reconstruction() will mark STRIPE_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT flag and R5_Wantdraian flag and set sh->reconstruct_state=reconstruct_state_drain_run for reconstruction write; or it will mark STRIPE_OP_PREXOR and STRIP_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT and R5_Wantdrain flags for read-modify-write. It will also lock appropriate buffers.
11. Raid5_run_ops() is called. For read-modiry-writes, it calls ops_run_prexor() to calculate the xor results for old data and old parity block. Then ops_run_biodrain() is called (for both rcw and rmw) to copy data from bio to per-disk-cache. Finally ops_run_reconstruct5() is called, which calculates the parity block contents.
12. Ops_run_io() is called to register I/O completion function to be raid5_end_write_request() and submit I/O request for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
13. Upon I/O completion, raid5_end_write_request() will clear R5_LOCKED flag and set STRIPE_HANDLE flag.
14. Again handle_stripe() is called, this time it does nothing but clear the STRIPE_HANDLE flag.
15. Control returns to make_request, which return the user-submitted bio.
linux software raid5 code reading notes (1)
Process of a typical read
1. When the bio corresponding to the read request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() would call handle_stripe_fill5(), which will in turn call fetch_block5(). Fetch_block5() will set the R5_LOCKED and R5_WantRead flags, while handle_stripe_fill5() will set the STRIPE_HANDLE flag (which was previously cleared by handle_stripe5()).
6. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
7. Raid5d then calls release_stripe(). Note: the I/O completion function raid5_end_read_request() and release_stripe() run in the same time???
8. Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Release_stripe() will again call handle_stripe() function. This time according to all the flags, handle_stripe() will call raiad_run_ops(), which will in turn call ops_run_biofill() to copy the data previous read to user-submitted bio asscociated buffer. Upon completion of this async coping, ops_complete_biofill() is called, which set STRIPE_HANDLE flag again.
10. This time handle_stripe() is called but it does nothing but clear STRIPE_HANDLE flag
11. Control returns to make_request, which calls bio_endio to return user-submitted bio.
12. Finally, calls into release_stripe() function which releases current stripe and if necessary, wake up raid5d to deal with other stipes.
1. When the bio corresponding to the read request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() would call handle_stripe_fill5(), which will in turn call fetch_block5(). Fetch_block5() will set the R5_LOCKED and R5_WantRead flags, while handle_stripe_fill5() will set the STRIPE_HANDLE flag (which was previously cleared by handle_stripe5()).
6. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
7. Raid5d then calls release_stripe(). Note: the I/O completion function raid5_end_read_request() and release_stripe() run in the same time???
8. Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Release_stripe() will again call handle_stripe() function. This time according to all the flags, handle_stripe() will call raiad_run_ops(), which will in turn call ops_run_biofill() to copy the data previous read to user-submitted bio asscociated buffer. Upon completion of this async coping, ops_complete_biofill() is called, which set STRIPE_HANDLE flag again.
10. This time handle_stripe() is called but it does nothing but clear STRIPE_HANDLE flag
11. Control returns to make_request, which calls bio_endio to return user-submitted bio.
12. Finally, calls into release_stripe() function which releases current stripe and if necessary, wake up raid5d to deal with other stipes.
2009年4月24日星期五
certified check & bank money order /bank draft（zz)
certified check & bank money order /bank draft(2008-11-08 23:32:51)
| 标签：杂谈 |
”字样 需要向银行购买，购买后一定金额
A．Certified check
需要向银行购买，购买后一定金额的保付支票后，存款账户上与支票等额的金额就会被冻结，收款人用支票到银行承兑时这部分金额才会被扣除。
B.Bank Money order (O/M)&bank bill/bank draft (B/D)都为 银行汇票
在购买后，存款帐户上与汇票等额的金额会被立即扣除。
这两大类票据对收款人来说都是保证支付的兑现的票据，bank draft有可能会被收取手续费。
的保付支票后，存款账户上与支票等额的金额对付款人来说，certified check手续费比bank draft
2009年3月9日星期一
Linux用iptables共享上网
1.在farm上的设置
打开ip转发：echo "1" >/proc/sys/net/ipv4/ip_forward
打开NAT：iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
2.在node上的设置
修改路由表：route del default (192.168.0.0/24的不要去动它）
route add default gw hepfarm02
修改dns文件：把/etc/resolv.conf改成如下内容：
search phy.pku.edu.cn
nameserver 162.105.129.26
nameserver 162.105.129.27
node连接未名测试通过
打开ip转发：echo "1" >/proc/sys/net/ipv4/ip_forward
打开NAT：iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
2.在node上的设置
修改路由表：route del default (192.168.0.0/24的不要去动它）
route add default gw hepfarm02
修改dns文件：把/etc/resolv.conf改成如下内容：
search phy.pku.edu.cn
nameserver 162.105.129.26
nameserver 162.105.129.27
node连接未名测试通过
2008年8月19日星期二
在64位机器上安装CMSSW
安装framework：
mkdir cms_work
source cmsset_default.sh
eval `scramv1 runtime -sh`
scramv1 list看一下可用的cmssw版本
scram p CMSSW CMSSW_x_y_z
go to the src directory and create a subdirectory and cd into it
Run mktsel
Edit the code
修改config/Buildfile.xml，参见https://twiki.cern.ch/twiki/bin/view/CMS/HamburgWikiComputingLocal#Compiling_CMSSW_with_the_slc3_Ar
Compile using scram b(之前需要先修改buildfile添加一些依赖关系，比如root）
Add gSystem->Load("/FULL/path/to/libNameOfYourSelector.so") to your rootlogon.C
in ROOT, connect to PROOF and then run chain->SetProof(); chain->Process("NameOfYourSelector")
tcsh创建工作环境：
setenv VO_CMS_SW_DIR $PWD
setenv SCRAM_ARCH slc4_ia32_gcc345
setenv LANG "C"
wget -O $VO_CMS_SW_DIR/bootstrap.sh http://cmsrep.cern.ch/cmssw/cms/bootstrap.sh
mkdir /tmp/$USER
sh -x $VO_CMS_SW_DIR/bootstrap.sh setup -path $VO_CMS_SW_DIR -arch $SCRAM_ARCH >& $VO_CMS_SW_DIR/bootstrap_$SCRAM_ARCH.log
source $VO_CMS_SW_DIR/$SCRAM_ARCH/external/apt/0.5.15lorg3.2-CMS19c/etc/profile.d/init.csh
apt-get update
apt-get install cms+cmssw+CMSSW_2_0_0_pre8
mkdir cms_work
source cmsset_default.sh
eval `scramv1 runtime -sh`
scramv1 list看一下可用的cmssw版本
scram p CMSSW CMSSW_x_y_z
go to the src directory and create a subdirectory and cd into it
Run mktsel
Edit the code
修改config/Buildfile.xml，参见https://twiki.cern.ch/twiki/bin/view/CMS/HamburgWikiComputingLocal#Compiling_CMSSW_with_the_slc3_Ar
Compile using scram b(之前需要先修改buildfile添加一些依赖关系，比如root）
Add gSystem->Load("/FULL/path/to/libNameOfYourSelector.so") to your rootlogon.C
in ROOT, connect to PROOF and then run chain->SetProof(); chain->Process("NameOfYourSelector")
2008年8月3日星期日
安装MPICH以及Lattice QCD测试环境
A: 我的笔记本，32位，fedora9，一个双核cpu B: DESY的测试机器hpbl1 64位 SL5 2个4核cpu
1.安装MPICH,我基本是按照这上面做的
http://hi.baidu.com/motioo/blog/item/a2a73bd02b2bd08da0ec9cc8.html
2.从这里下载BenchMZ.tar.gz,照着readme的说法往下做
http://www-zeuthen.desy.de/~yangsuli/
3.Make中遇到的问题:
/bin/mpicc不存在: 设置环境变量MPIR_HOME
cc1: 错误：无法识别的命令行选项“-fno-force-mem” -fno-force-mem这个选项在gcc4.3已经被remove了,在4.3下面no-op. 在fc下重新装了一个gcc3.4.6
配置选项:../configure --prefix=/usr/local/gcc34 --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk
这是DESY机器gcc的标准配置，我只是改了prefix，另外把--host=x86_64_redhat_linux删掉了
check1.c:1: error: CPU you selected does not support x86-64 instruction set
check1.c:1: error: -malign-double makes no sense in the 64bit mode
Makefile里指定了只有32位机器才能用的编译选项...i586啥的...没啥说的，只能改
但是到底怎么改，必须有一个统一的说法。 还有就是天知道源代码里有没有针对32位机器的优化...
4. 执行过程中遇到的问题
Actual CPU 和 NPROC数目不符....他把CPU GRID的规模指定在源代码里了...(include/global.h)
在我自己的笔记本上是先用mpirun -n 32虚拟了一个32core的环境...估计还得改原代码...sigh
TODO:
查查互联网上有人做lattice QCD benchmarking的结果，这老兄写的BenchMZ也太不靠谱了...
看看他打的这个包跟人家真正给的做计算的代码有哪些差别，跟supervisor讨论一个合理的编译flag出来
1.安装MPICH,我基本是按照这上面做的
http://hi.baidu.com/motioo/blog/item/a2a73bd02b2bd08da0ec9cc8.html
2.从这里下载BenchMZ.tar.gz,照着readme的说法往下做
http://www-zeuthen.desy.de/~yangsuli/
3.Make中遇到的问题:
/bin/mpicc不存在: 设置环境变量MPIR_HOME
cc1: 错误：无法识别的命令行选项“-fno-force-mem” -fno-force-mem这个选项在gcc4.3已经被remove了,在4.3下面no-op. 在fc下重新装了一个gcc3.4.6
配置选项:../configure --prefix=/usr/local/gcc34 --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk
这是DESY机器gcc的标准配置，我只是改了prefix，另外把--host=x86_64_redhat_linux删掉了
check1.c:1: error: CPU you selected does not support x86-64 instruction set
check1.c:1: error: -malign-double makes no sense in the 64bit mode
Makefile里指定了只有32位机器才能用的编译选项...i586啥的...没啥说的，只能改
但是到底怎么改，必须有一个统一的说法。 还有就是天知道源代码里有没有针对32位机器的优化...
4. 执行过程中遇到的问题
Actual CPU 和 NPROC数目不符....他把CPU GRID的规模指定在源代码里了...(include/global.h)
在我自己的笔记本上是先用mpirun -n 32虚拟了一个32core的环境...估计还得改原代码...sigh
TODO:
查查互联网上有人做lattice QCD benchmarking的结果，这老兄写的BenchMZ也太不靠谱了...
看看他打的这个包跟人家真正给的做计算的代码有哪些差别，跟supervisor讨论一个合理的编译flag出来
订阅：
博文 (Atom)