Shell's Home

上下文切换测试总结报告

Nov 18, 2014 - 2 minute read - Comments

效率测试 测试环境 Intel® Pentium® CPU G2030 @ 3.00GHz 8G内存 debian jessie Linux 3.16-2-amd64 2014年10月27日 附注一下,该CPU有2核心,无HT,1ns3个时钟周期。 测试方法 测试代码如下: time -f "%e,%S,%c,%r,%s,%K,%P" ./perf_fork 数据的意义分别为: 总时间,内核CPU时间,context switch次数,读/写次数,内存耗用,CPU使用百分比。 数据处理方法如下: import numpy as np p = lambda s: [float(line.strip().split(',')[0]) for line in s.splitlines()] q = lambda s: [float(line.strip().split(',')[1]) for line in s.splitlines()] np.array(p(s)).mean() np.array(p(s)).var() np.array(q(s)).mean() np.array(q(s)).var() 基础开销测试 函数调用开销 使用s_call来测试性能,循环1G次。 2.35,0.00,17,0,0,0,99% 2.34,0.00,13,0,0,0,99% 2.34,0.00,10,0,0,0,100% 2.35,0.00,10,0,0,0,99% 2.34,0.00,14,0,0,0,99% 2.34,0.00,6,0,0,0,99% 统计结果如下: time mean = 2.34 time var = 0.000022 每次call的开销为2.34ns,约7个指令周期。当然,这些并没有考虑调用压栈和数据返回。

手机上app的权限对比和分析

Nov 7, 2014 - 2 minute read - Comments

简述 今天看到这篇文章,勾起了我的好奇。我的手机里有多少app有安全隐患呢?当然,我知道很多有安全问题的app我不能删——例如企鹅家。但是如果某个app没有必然需要,或者有替代品。我不介意换一个用。所以我写了这篇blog,对比了各种同类或近似app的权限要求。 先说明一点,这篇文章所列出的app权限,是根据当前(2014-11-07)google play上的应用权限数据,截取我感兴趣的部分权限汇总的。既不是完全的敏感权限列表,也不可能不变化。如果有什么补充,欢迎你联系我。 同时你需要知道,app需要某个权限,并不一定表示要用来做坏事。很多时候是因为功能确实需要。因此我也在下面点评了部分我知道的功能需要对应权限。即便我们在app里面找不到权限对应功能,也不能绝对断言app正在作恶——只是相比起来我更信任不需要提供这个权限的app而已。这也是为什么我做的是分类对比——方便你来比较和替换。 IM类 telegram read SMS 照相 录音 location read/modify contacts run at startup talkback change audio setting 我太感动了。 QQ read SMS read/modify contacts 照相 录音 location read/write call log read/write calendar disable screen lock NFC bluetooth run at startup change audio setting 流氓权限大集合啊。你说要contacts我还能理解,要call log干嘛?还要write?而且功能里也找不到为什么需要NFC和蓝牙。 微信 read SMS 照相 录音 location read/modify contacts bluetooth run at startup change audio setting 基本同QQ,不过权限少了很多。 评论 虽然我们都知道talkback比企鹅家的对隐私更友好,可是有本事你别用企鹅家。。。 SNS facebook read sms

context切换测试——C语言协程有关部分请求review

Nov 6, 2014 - 1 minute read - Comments

setjmp/longjmp测试 使用s_jmp程序来测试setjmp的性能。1G次循环。下面是结论: 5.77,0.00,29,0,0,0,99% 5.70,0.00,30,0,0,0,99% 5.71,0.00,22,0,0,0,99% 5.71,0.00,23,0,0,0,99% 5.70,0.00,30,0,0,0,100% 5.70,0.00,23,0,0,0,99% 统计结果如下: time mean = 5.715 time var = 0.000625 单次调度开销只有5.7ns,在所有测试中性能最优。(glibc-2.19/sysdeps/x86_64/setjmp.S) getcontext/setcontext测试 使用s_context程序来测试setcontext的性能。100M次循环。下面是结论: 12.96,5.88,79,0,0,0,99% 13.13,5.94,105,0,0,0,99% 12.95,6.18,57,0,0,0,99% 13.13,5.90,64,0,0,0,99% 12.95,5.88,82,0,0,0,99% 12.96,5.80,51,0,0,0,99% 统计结果如下: time mean = 13.01 time var = 0.0068 单次调度开销高达130ns,仅比系统的sched在高线程下略快。这事很奇怪,因为根据我看到的源码(glibc-2.19/sysdeps/unix/sysv/linux/x86_64/setcontext.S),getcontext/setcontext在glibc中是用汇编实现的。其中陷入内核只是为了设定signal mask。

context切换测试——线程创建有关部分请求review

Oct 31, 2014 - 1 minute read - Comments

线程模式开销 使用t_thread程序,循环1M次,重复6次,原始数据如下: 9.57,8.22,21098,0,0,0,104% 9.77,8.40,29704,0,0,0,104% 9.36,8.17,10390,0,0,0,106% 9.56,8.50,14514,0,0,0,107% 9.35,8.34,7244,0,0,0,108% 9.57,8.43,26351,0,0,0,106% 统计结果如下: time mean = 9.53 time var = 0.02 kernel mean = 8.34 kernel var = 0.013 解读数据可以看到,thread模式的开销为9530ns(已经降到纳秒级了),CPU将为8340ns,精确级别在20ns级别。粗略换算一下每次create的开销大约是30k个时钟周期。简单对比可以看出,thread模式比fork模式大约快了5倍。

context切换测试——调用开销有关部分请求review

Oct 30, 2014 - 1 minute read - Comments

函数调用开销 使用s_call来测试性能,循环1G次。 2.35,0.00,17,0,0,0,99% 2.34,0.00,13,0,0,0,99% 2.34,0.00,10,0,0,0,100% 2.35,0.00,10,0,0,0,99% 2.34,0.00,14,0,0,0,99% 2.34,0.00,6,0,0,0,99% 统计结果如下: time mean = 2.34 time var = 0.000022 每次call的开销为2.34ns,约7个指令周期。当然,这些并没有考虑调用压栈和数据返回。 内核调用开销 使用s_syscall来测试性能,循环1G次。这里特意选用了一个不可能失败的内核函数,getpid,来衡量每次进入getpid的开销。 4.37,0.00,76,0,0,0,99% 4.34,0.00,43,0,0,0,99% 4.37,0.00,124,0,0,0,99% 4.37,0.00,63,0,0,0,99% 4.36,0.00,48,0,0,0,99% 4.36,0.00,47,0,0,0,99% 统计结果如下: time mean = 4.36 time var = 0.00011 这里可以看到,纯粹的内核进入开销小到非常惊人,只有4.36ns,约合13个指令周期,而且这里还要进行数据的查询和返回。所以内核调用开销在下面的测试中全部忽略不计。

context切换测试——python有关部分请求review

Oct 29, 2014 - 1 minute read - Comments

python yield模式性能测试 python下的测试就不用time了,我们改用python的timeit,循环100M次。具体可以看py_yield.py。数据结果如下: 7.64262938499 9.2919304393e-06 5.41777145863 4.94284924931e-06 从结果来看,100M次循环的平均时间是5.4s,平均每次大约54ns。使用yield后变为76ns,增加了22ns。 python greenlet模式性能测试 这次代码在py_greenlet.py,循环10M次。数据结果如下: 5.35270996888 7.44085846125e-05 5.31448976199 5.82336765673e-05 单次循环时间消耗为535ns。比最初的54ns,增加了481ns。基本来说,时间增长了10倍率。 这是预料中的,因为greenlet早就声明自己通过堆栈拷贝来实现上下文切换。这会消耗大量CPU时间。从原理上说,栈越深,消耗越大。但是测试结果表明两者几乎没有差异,栈深反而性能更加优异(TODO: why?)。

context切换测试——进程有关部分请求review

Oct 28, 2014 - 1 minute read - Comments

测试环境 Intel® Pentium® CPU G2030 @ 3.00GHz 8G内存 debian jessie Linux 3.16-2-amd64 2014年10月27日 附注一下,该CPU有2核心,无HT,1ns3个时钟周期。 测试方法 测试代码如下: time -f "%e,%S,%c,%r,%s,%K,%P" ./perf_fork 数据的意义分别为: 总时间,占用CPU时间,context switch次数,读/写次数,内存耗用,CPU使用百分比。 数据处理方法如下: import numpy as np p = lambda s: [float(line.strip().split(',')[0]) for line in s.splitlines()] q = lambda s: [float(line.strip().split(',')[1]) for line in s.splitlines()] np.array(p(s)).mean() np.array(p(s)).var() np.array(q(s)).mean() np.array(q(s)).var() 进程fork开销 使用s_fork程序(注释语句关闭模式),粒度1M次,重复6次,原始数据如下: 49.04,26.83,29784,0,0,0,55% 51.53,26.38,32057,0,0,0,52% 49.88,26.02,30892,0,0,0,53% 51.39,27.13,37573,0,0,0,54% 52.89,28.12,37924,0,0,0,54% 51.19,27.02,35880,0,0,0,54% 统计结果如下: time mean = 50.98 time var = 1.52 cpu mean =

bash严重漏洞

Sep 25, 2014 - 1 minute read - Comments

今天估计各大消息都在报这个漏洞,可能有些人看到有修复就放松了。目前来看,事情没那么简单。 CVE-2014-6271 第一个漏洞,编号为CVE-2014-6271。相应的dsa和usn。 具体的文章可以看这里。 简单来说,当bash执行时看到有变量定义了一个函数,函数尾部又剩余了部分代码。会直接把剩余代码执行了。导致简单的变量定义动作有机会执行任意代码。 对于未修补的系统,执行以下代码出现以下提示: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test 注意echo vulnerable应当不被执行的。 修复的系统则是以下表现: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test CVE-2014-7169 第二个漏洞,编号为CVE-2014-7169。 这个漏洞是第一个漏洞没有修复完全导致的,最麻烦的是,这个漏洞没有修复,细节却满天飞了。 表现如下: $ env X='() { (a)=>\' sh

送书

Sep 4, 2014 - 1 minute read - Comments

最近清理家中藏书,打算送掉一部分纸质书。于是顺手列了一批自己需要,但是可以外借的书。 送人的部分,如果你需要,两个月内联系我,自己想办法拿走(例如H4,或者直接上门)。逾期我就直接送去资源回收了。借阅的部分,记得好好保管图书,不管借阅多久,记得回头还我。 送人 delphi 5.0 开发多媒体应用 ISBN 7-5084-0470-X C++语言程序设计 ISBN 7-302-03926-7 计算机绘图 ISBN 7-313-01482-1/TP.273 borland C++ windows程序设计 ISBN 7-115-05265-4/TP.117 最新C++语言精华 ISBN 7-5053-3975-3/TP.1731 C++语言程序设计 ISBN 7-302-04504-6 C++使用手册 ISBN 7-5053-2890-5/TP.959 microsoft visual C++ .net技术内幕 ISBN 7-302-08931-0 操作系统教程 ISBN 7-04-012664-8 借阅 模式识别 ISBN 7-121-02647-3 深入解析Windows操作系统 ISBN 978-7-121-03969-0 计算机网络 ISBN 7-302-08977-9 深入浅出MFC ISBN 7-900614-93-1 Python源码解析 ISBN 978-7-121-06874-4 数据结构与算法(Java语言版) ISBN 7-111-11902-9 网络渗透技术 ISBN 7-121-01035-6 密码编码学与网络安全 ISBN 7-5053-9395-2 人工智能及其应用 ISBN 7-302-02127-9 神经网络原理 ISBN 7-111-12759-5

如何分辨网站真假

Aug 19, 2014 - 1 minute read - Comments

老婆想去新疆玩,结果她居然从百度上搜了一下新疆国旅就联系开了。我一直不知道,直到她和我说,对方要求缴500元到一个支付宝帐号里。我立刻要求她不要付钱,然后开始查证真假。 第一家网站 她开始给我的是这家:http://www.17xjly.net/。 老规矩,先whois,再dig,再whois。 whois域名的结果是没有任何信息?! dig后的IP是113.10.247.20。再whois一遍,发现服务器在香港。此外也没有任何信息。 ICP是新疆的,查全国ICP登记无信息。 开始想不通,这家伙在新疆背景这么深厚?突然醒悟过来。这家伙是个.net域名,注册地不在中国,服务器不在中国,凭什么要人家ICP备案啊。就因为号称是新疆的网站? CAO,这种网站给的支付宝,鬼知道打进去会发生什么。。。 第二家网站 百度上排名很高的是这家http://www.yuyutrip.net/和这家http://www.yoyotrip.net/。两家的页面很像,但是又明显有区别,不知道是竞争对手还是什么。 老规矩。 whois域名的结果是这个: Registrant State/Province:Shanghai Registrant Name:shxg shxg 注册地上海? dig了更好玩。这两个域名的IP指向是同一个。121.52.217.137。再whois发现是这个: netname: TopnewNET descr: Beijing Topnew Info&Tech co., LTD. 没听说过。 ICP倒是有: 北京博通天下网络技术有限公司 U旅商旅网 2013-06-09 咳咳,漏底了吧。虽然号称国旅,但是是一家北京公司在上海注册的域名。 好玩的是,这家网站上面给出的地址,是真的(具体后面会说)。但是电话却不对。 真的国旅 google出手,马上就有。结果是这个http://www.cits.com.cn。 老规矩。 whois域名可以看到这个: Registrant: 中国国际旅行社总社有限公司 注册者看着就很NB。 dig一下,发现IP是这个,219.143.192.35。这个IP可牛逼了。whois一下: inetnum: 219.143.192.0 - 219.143.192.255 netname: CITS 我擦,专属C类IP段! ICP查询后结果是这样的: 中国国际旅行社总社有限公司 国旅在线 www.cits.com.cn 2014-07-23 www.cits.net 2012-11-29 这个网站上有400电话,打过去说新疆只有团体游。不过人家给了正确的地址和电话,和第二家网站的地址一致,电话却不一样。 事情到这里,我的基本判断是。和第二家网站做生意还是有点谱的,ICP是真的,地址国旅也认。最低限度,他至少是一家合法的旅行社——虽然不保证是国旅下属。第一家么,谁爱信谁信。 上海国旅 后面有点更好玩的事情。国旅在线上有上海,而google查询结果上也有不少上海国旅。那么谁是真的呢? 上海国旅1 例如这家http://www.scits.com/。 域名的whois是这样的: Registrant Organization: SHANGHAI CHINA INTERNATIONAL TRAVEL SERVICE CO.,LT Registrant City: shanghai dig后发现IP是210.14.68.234,再whois是这样的: netname: SVA descr: Science & Technology Network Communication Co., Ltd.