From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 00:03:40 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B467B16A418 for ; Tue, 18 Sep 2007 00:03:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 54EF413C428 for ; Tue, 18 Sep 2007 00:03:39 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8I032Gr077693 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Sep 2007 20:03:03 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 17 Sep 2007 17:05:57 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: arch@freebsd.org Message-ID: <20070917165657.B558@10.0.0.1> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2003406049-1190073957=:558" Cc: Subject: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 00:03:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2003406049-1190073957=:558 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Enclosed is a patch that fixes swapping with ULE. ULE has never properly set p_swtime and td_slptime which are used by the swapout/swapin code to select the appropriate thread to swap. In 4BSD these two variables are increment once per-second as schedcpu() iterates over all threads. ULE does not have a once per-second loop iterating over all threads. So I have changed p_swtime to p_swtick and td_slptime to td_slptick. These record the value of 'ticks' when the thread slept or was last swapped in or out. For backwards compatibility I leave the values in kinfo_proc with the legacy meaning by subtracting from ticks and dividing by hz. I perform a similar transformation in the swapout code to convert to seconds. This change does make it possible to use sub-second granular decisions in the swap code, however I'm not sure if that's really necessary. So that I did not disturb the 4BSD mechanism I kept the original td_slptime in the td_sched area. It should be possible to use td_slptick directly but especially this close to release I did not want to change 4BSD. Feedback and testing welcome. Thanks, Jeff --0-2003406049-1190073957=:558 Content-Type: TEXT/x-diff; charset=US-ASCII; name=swap2.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070917170557.P558@10.0.0.1> Content-Description: Content-Disposition: attachment; filename=swap2.diff SW5kZXg6IGxpYi9saWJrdm0va3ZtX3Byb2MuYw0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL2xpYi9saWJrdm0v a3ZtX3Byb2MuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuOTMNCmRpZmYg LXUgLXAgLXIxLjkzIGt2bV9wcm9jLmMNCi0tLSBsaWIvbGlia3ZtL2t2bV9w cm9jLmMJMTcgU2VwIDIwMDcgMDU6Mjc6MTggLTAwMDAJMS45Mw0KKysrIGxp Yi9saWJrdm0va3ZtX3Byb2MuYwkxNyBTZXAgMjAwNyAwNTo1ODowOSAtMDAw MA0KQEAgLTg1LDYgKzg1LDkgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBzcmMv bGliL2xpYmt2bS9rdm1fcA0KICNkZWZpbmUgS1JFQUQoa2QsIGFkZHIsIG9i aikgXA0KIAkoa3ZtX3JlYWQoa2QsIGFkZHIsIChjaGFyICopKG9iaiksIHNp emVvZigqb2JqKSkgIT0gc2l6ZW9mKCpvYmopKQ0KIA0KK2ludCB0aWNrczsN CitpbnQgaHo7DQorDQogLyoNCiAgKiBSZWFkIHByb2MncyBmcm9tIG1lbW9y eSBmaWxlIGludG8gYnVmZmVyIGJwLCB3aGljaCBoYXMgc3BhY2UgdG8gaG9s ZA0KICAqIGF0IG1vc3QgbWF4Y250IHByb2NzLg0KQEAgLTM2OCw3ICszNzEs NyBAQCBub3BncnA6DQogCQlrcC0+a2lfYWNmbGFnID0gcHJvYy5wX2FjZmxh ZzsNCiAJCWtwLT5raV9sb2NrID0gcHJvYy5wX2xvY2s7DQogCQlpZiAocHJv Yy5wX3N0YXRlICE9IFBSU19aT01CSUUpIHsNCi0JCQlrcC0+a2lfc3d0aW1l ID0gcHJvYy5wX3N3dGltZTsNCisJCQlrcC0+a2lfc3d0aW1lID0gKHRpY2tz IC0gcHJvYy5wX3N3dGljaykgLyBoejsNCiAJCQlrcC0+a2lfZmxhZyA9IHBy b2MucF9mbGFnOw0KIAkJCWtwLT5raV9zZmxhZyA9IDA7DQogCQkJa3AtPmtp X25pY2UgPSBwcm9jLnBfbmljZTsNCkBAIC01MzUsMTIgKzUzOCwxNCBAQCBr dm1fZ2V0cHJvY3Moa2QsIG9wLCBhcmcsIGNudCkNCiBsaXZlb3V0Og0KIAkJ bnByb2NzID0gc2l6ZSA9PSAwID8gMCA6IHNpemUgLyBrZC0+cHJvY2Jhc2Ut PmtpX3N0cnVjdHNpemU7DQogCX0gZWxzZSB7DQotCQlzdHJ1Y3Qgbmxpc3Qg bmxbNF0sICpwOw0KKwkJc3RydWN0IG5saXN0IG5sWzZdLCAqcDsNCiANCiAJ CW5sWzBdLm5fbmFtZSA9ICJfbnByb2NzIjsNCiAJCW5sWzFdLm5fbmFtZSA9 ICJfYWxscHJvYyI7DQogCQlubFsyXS5uX25hbWUgPSAiX3pvbWJwcm9jIjsN Ci0JCW5sWzNdLm5fbmFtZSA9IDA7DQorCQlubFszXS5uX25hbWUgPSAiX3Rp Y2tzIjsNCisJCW5sWzRdLm5fbmFtZSA9ICJfaHoiOw0KKwkJbmxbNV0ubl9u YW1lID0gMDsNCiANCiAJCWlmIChrdm1fbmxpc3Qoa2QsIG5sKSAhPSAwKSB7 DQogCQkJZm9yIChwID0gbmw7IHAtPm5fdHlwZSAhPSAwOyArK3ApDQpAQCAt NTUzLDYgKzU1OCwxNCBAQCBsaXZlb3V0Og0KIAkJCV9rdm1fZXJyKGtkLCBr ZC0+cHJvZ3JhbSwgImNhbid0IHJlYWQgbnByb2NzIik7DQogCQkJcmV0dXJu ICgwKTsNCiAJCX0NCisJCWlmIChLUkVBRChrZCwgbmxbM10ubl92YWx1ZSwg JnRpY2tzKSkgew0KKwkJCV9rdm1fZXJyKGtkLCBrZC0+cHJvZ3JhbSwgImNh bid0IHJlYWQgdGlja3MiKTsNCisJCQlyZXR1cm4gKDApOw0KKwkJfQ0KKwkJ aWYgKEtSRUFEKGtkLCBubFs0XS5uX3ZhbHVlLCAmaHopKSB7DQorCQkJX2t2 bV9lcnIoa2QsIGtkLT5wcm9ncmFtLCAiY2FuJ3QgcmVhZCBoeiIpOw0KKwkJ CXJldHVybiAoMCk7DQorCQl9DQogCQlzaXplID0gbnByb2NzICogc2l6ZW9m KHN0cnVjdCBraW5mb19wcm9jKTsNCiAJCWtkLT5wcm9jYmFzZSA9IChzdHJ1 Y3Qga2luZm9fcHJvYyAqKV9rdm1fbWFsbG9jKGtkLCBzaXplKTsNCiAJCWlm IChrZC0+cHJvY2Jhc2UgPT0gMCkNCkluZGV4OiBzeXMva2Vybi9rZXJuX2Zv cmsuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21l L25jdnMvc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jLHYNCnJldHJpZXZpbmcg cmV2aXNpb24gMS4yODENCmRpZmYgLXUgLXAgLXIxLjI4MSBrZXJuX2Zvcmsu Yw0KLS0tIHN5cy9rZXJuL2tlcm5fZm9yay5jCTE3IFNlcCAyMDA3IDA1OjI3 OjIwIC0wMDAwCTEuMjgxDQorKysgc3lzL2tlcm4va2Vybl9mb3JrLmMJMTcg U2VwIDIwMDcgMDU6NDg6NTMgLTAwMDANCkBAIC01MDAsNiArNTAwLDcgQEAg YWdhaW46DQogCSAqIEluY3JlYXNlIHJlZmVyZW5jZSBjb3VudHMgb24gc2hh cmVkIG9iamVjdHMuDQogCSAqLw0KIAlwMi0+cF9mbGFnID0gUF9JTk1FTTsN CisJcDItPnBfc3d0aWNrID0gdGlja3M7DQogCWlmIChwMS0+cF9mbGFnICYg UF9QUk9GSUwpDQogCQlzdGFydHByb2ZjbG9jayhwMik7DQogCXRkMi0+dGRf dWNyZWQgPSBjcmhvbGQocDItPnBfdWNyZWQpOw0KSW5kZXg6IHN5cy9rZXJu L2tlcm5fcHJvYy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmls ZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmMsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjI1MQ0KZGlmZiAtdSAtcCAtcjEuMjUxIGtl cm5fcHJvYy5jDQotLS0gc3lzL2tlcm4va2Vybl9wcm9jLmMJMTcgU2VwIDIw MDcgMDU6Mjc6MjAgLTAwMDAJMS4yNTENCisrKyBzeXMva2Vybi9rZXJuX3By b2MuYwkxNyBTZXAgMjAwNyAwNjowMzoyMSAtMDAwMA0KQEAgLTY5NCw3ICs2 OTQsOCBAQCBmaWxsX2tpbmZvX3Byb2Nfb25seShzdHJ1Y3QgcHJvYyAqcCwg c3RyDQogCQlrcC0+a2lfc2ZsYWcgPSBQU19JTk1FTTsNCiAJZWxzZQ0KIAkJ a3AtPmtpX3NmbGFnID0gMDsNCi0Ja3AtPmtpX3N3dGltZSA9IHAtPnBfc3d0 aW1lOw0KKwkvKiBDYWxjdWxhdGUgbGVnYWN5IHN3dGltZSBhcyBzZWNvbmRz IHNpbmNlICdzd3RpY2snLiAqLw0KKwlrcC0+a2lfc3d0aW1lID0gKHRpY2tz IC0gcC0+cF9zd3RpY2spIC8gaHo7DQogCWtwLT5raV9waWQgPSBwLT5wX3Bp ZDsNCiAJa3AtPmtpX25pY2UgPSBwLT5wX25pY2U7DQogCXJ1ZmV0Y2gocCwg JmtwLT5raV9ydXNhZ2UpOw0KQEAgLTgxMiw3ICs4MTMsNyBAQCBmaWxsX2tp bmZvX3RocmVhZChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RyDQogCWtwLT5raV9r c3RhY2sgPSAodm9pZCAqKXRkLT50ZF9rc3RhY2s7DQogCWtwLT5raV9wY3Rj cHUgPSBzY2hlZF9wY3RjcHUodGQpOw0KIAlrcC0+a2lfZXN0Y3B1ID0gdGQt PnRkX2VzdGNwdTsNCi0Ja3AtPmtpX3NscHRpbWUgPSB0ZC0+dGRfc2xwdGlt ZTsNCisJa3AtPmtpX3NscHRpbWUgPSAodGlja3MgLSB0ZC0+dGRfc2xwdGlj aykgLyBoejsNCiAJa3AtPmtpX3ByaS5wcmlfY2xhc3MgPSB0ZC0+dGRfcHJp X2NsYXNzOw0KIAlrcC0+a2lfcHJpLnByaV91c2VyID0gdGQtPnRkX3VzZXJf cHJpOw0KIA0KSW5kZXg6IHN5cy9rZXJuL2tlcm5fdGhyZWFkLmMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9z eXMva2Vybi9rZXJuX3RocmVhZC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24g MS4yNTMNCmRpZmYgLXUgLXAgLXIxLjI1MyBrZXJuX3RocmVhZC5jDQotLS0g c3lzL2tlcm4va2Vybl90aHJlYWQuYwkxNyBTZXAgMjAwNyAwNToyNzoyMCAt MDAwMAkxLjI1Mw0KKysrIHN5cy9rZXJuL2tlcm5fdGhyZWFkLmMJMTcgU2Vw IDIwMDcgMjM6NTY6NDUgLTAwMDANCkBAIC04NTIsNiArODUyLDcgQEAgdGhy ZWFkX3N1c3BlbmRfc3dpdGNoKHN0cnVjdCB0aHJlYWQgKnRkKQ0KIAlwLT5w X3N1c3Bjb3VudCsrOw0KIAlQUk9DX1VOTE9DSyhwKTsNCiAJdGhyZWFkX2xv Y2sodGQpOw0KKwlzY2hlZF9zbGVlcCh0ZCk7DQogCVREX1NFVF9TVVNQRU5E RUQodGQpOw0KIAlQUk9DX1NVTkxPQ0socCk7DQogCURST1BfR0lBTlQoKTsN CkBAIC04NzEsNiArODcyLDcgQEAgdGhyZWFkX3N1c3BlbmRfb25lKHN0cnVj dCB0aHJlYWQgKnRkKQ0KIAlUSFJFQURfTE9DS19BU1NFUlQodGQsIE1BX09X TkVEKTsNCiAJS0FTU0VSVCghVERfSVNfU1VTUEVOREVEKHRkKSwgKCJhbHJl YWR5IHN1c3BlbmRlZCIpKTsNCiAJcC0+cF9zdXNwY291bnQrKzsNCisJc2No ZWRfc2xlZXAodGQpOw0KIAlURF9TRVRfU1VTUEVOREVEKHRkKTsNCiB9DQog DQpJbmRleDogc3lzL2tlcm4vc2NoZWRfNGJzZC5jDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4v c2NoZWRfNGJzZC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMDQNCmRp ZmYgLXUgLXAgLXIxLjEwNCBzY2hlZF80YnNkLmMNCi0tLSBzeXMva2Vybi9z Y2hlZF80YnNkLmMJMTcgU2VwIDIwMDcgMDU6Mjc6MjAgLTAwMDAJMS4xMDQN CisrKyBzeXMva2Vybi9zY2hlZF80YnNkLmMJMTcgU2VwIDIwMDcgMDY6MDY6 MzkgLTAwMDANCkBAIC04NCw2ICs4NCw3IEBAIHN0cnVjdCB0ZF9zY2hlZCB7 DQogCWZpeHB0X3QJCXRzX3BjdGNwdTsJLyogKGopICVjcHUgZHVyaW5nIHBf c3d0aW1lLiAqLw0KIAl1X2NoYXIJCXRzX3JxaW5kZXg7CS8qIChqKSBSdW4g cXVldWUgaW5kZXguICovDQogCWludAkJdHNfY3B0aWNrczsJLyogKGopIFRp Y2tzIG9mIGNwdSB0aW1lLiAqLw0KKwlpbnQJCXRzX3NscHRpbWU7CS8qIChq KSBTZWNvbmRzICFSVU5OSU5HLiAqLw0KIAlzdHJ1Y3QgcnVucQkqdHNfcnVu cTsJLyogcnVucSB0aGUgdGhyZWFkIGlzIGN1cnJlbnRseSBvbiAqLw0KIH07 DQogDQpAQCAtMzc5LDExICszODAsNiBAQCBzY2hlZGNwdSh2b2lkKQ0KIAlz eF9zbG9jaygmYWxscHJvY19sb2NrKTsNCiAJRk9SRUFDSF9QUk9DX0lOX1NZ U1RFTShwKSB7DQogCQlQUk9DX1NMT0NLKHApOw0KLQkJLyoNCi0JCSAqIElu Y3JlbWVudCB0aW1lIGluL291dCBvZiBtZW1vcnkuICBXZSBpZ25vcmUgb3Zl cmZsb3c7IHdpdGgNCi0JCSAqIDE2LWJpdCBpbnQncyAocmVtZW1iZXIgdGhl bT8pIG92ZXJmbG93IHRha2VzIDQ1IGRheXMuDQotCQkgKi8NCi0JCXAtPnBf c3d0aW1lKys7DQogCQlGT1JFQUNIX1RIUkVBRF9JTl9QUk9DKHAsIHRkKSB7 IA0KIAkJCWF3YWtlID0gMDsNCiAJCQl0aHJlYWRfbG9jayh0ZCk7DQpAQCAt NDQwLDcgKzQzNiw3IEBAIFhYWCAgdGhpcyBpcyBicm9rZW4NCiANCiAJCQkg Ki8NCiAJCQlpZiAoYXdha2UpIHsNCi0JCQkJaWYgKHRkLT50ZF9zbHB0aW1l ID4gMSkgew0KKwkJCQlpZiAodHMtPnRzX3NscHRpbWUgPiAxKSB7DQogCQkJ CQkvKg0KIAkJCQkJICogSW4gYW4gaWRlYWwgd29ybGQsIHRoaXMgc2hvdWxk IG5vdA0KIAkJCQkJICogaGFwcGVuLCBiZWNhdXNlIHdob2V2ZXIgd29rZSB1 cw0KQEAgLTQ1MiwxMCArNDQ4LDEwIEBAIFhYWCAgdGhpcyBpcyBicm9rZW4N CiAJCQkJCSAqLw0KIAkJCQkJdXBkYXRlcHJpKHRkKTsNCiAJCQkJfQ0KLQkJ CQl0ZC0+dGRfc2xwdGltZSA9IDA7DQorCQkJCXRzLT50c19zbHB0aW1lID0g MDsNCiAJCQl9IGVsc2UNCi0JCQkJdGQtPnRkX3NscHRpbWUrKzsNCi0JCQlp ZiAodGQtPnRkX3NscHRpbWUgPiAxKSB7DQorCQkJCXRzLT50c19zbHB0aW1l Kys7DQorCQkJaWYgKHRzLT50c19zbHB0aW1lID4gMSkgew0KIAkJCQl0aHJl YWRfdW5sb2NrKHRkKTsNCiAJCQkJY29udGludWU7DQogCQkJfQ0KQEAgLTQ5 MCwxNiArNDg2LDE4IEBAIHNjaGVkY3B1X3RocmVhZCh2b2lkKQ0KIHN0YXRp YyB2b2lkDQogdXBkYXRlcHJpKHN0cnVjdCB0aHJlYWQgKnRkKQ0KIHsNCi0J cmVnaXN0ZXIgZml4cHRfdCBsb2FkZmFjOw0KLQlyZWdpc3RlciB1bnNpZ25l ZCBpbnQgbmV3Y3B1Ow0KKwlzdHJ1Y3QgdGRfc2NoZWQgKnRzOw0KKwlmaXhw dF90IGxvYWRmYWM7DQorCXVuc2lnbmVkIGludCBuZXdjcHU7DQogDQorCXRz ID0gdGQtPnRkX3NjaGVkOw0KIAlsb2FkZmFjID0gbG9hZGZhY3RvcihhdmVy dW5uYWJsZS5sZGF2Z1swXSk7DQotCWlmICh0ZC0+dGRfc2xwdGltZSA+IDUg KiBsb2FkZmFjKQ0KKwlpZiAodHMtPnRzX3NscHRpbWUgPiA1ICogbG9hZGZh YykNCiAJCXRkLT50ZF9lc3RjcHUgPSAwOw0KIAllbHNlIHsNCiAJCW5ld2Nw dSA9IHRkLT50ZF9lc3RjcHU7DQotCQl0ZC0+dGRfc2xwdGltZS0tOwkvKiB3 YXMgaW5jcmVtZW50ZWQgaW4gc2NoZWRjcHUoKSAqLw0KLQkJd2hpbGUgKG5l d2NwdSAmJiAtLXRkLT50ZF9zbHB0aW1lKQ0KKwkJdHMtPnRzX3NscHRpbWUt LTsJLyogd2FzIGluY3JlbWVudGVkIGluIHNjaGVkY3B1KCkgKi8NCisJCXdo aWxlIChuZXdjcHUgJiYgLS10cy0+dHNfc2xwdGltZSkNCiAJCQluZXdjcHUg PSBkZWNheV9jcHUobG9hZGZhYywgbmV3Y3B1KTsNCiAJCXRkLT50ZF9lc3Rj cHUgPSBuZXdjcHU7DQogCX0NCkBAIC04MjcsNyArODI1LDggQEAgc2NoZWRf c2xlZXAoc3RydWN0IHRocmVhZCAqdGQpDQogew0KIA0KIAlUSFJFQURfTE9D S19BU1NFUlQodGQsIE1BX09XTkVEKTsNCi0JdGQtPnRkX3NscHRpbWUgPSAw Ow0KKwl0ZC0+dGRfc2xwdGljayA9IHRpY2tzOw0KKwl0ZC0+dGRfc2NoZWQt PnRzX3NscHRpbWUgPSAwOw0KIH0NCiANCiB2b2lkDQpAQCAtOTM5LDEyICs5 MzgsMTYgQEAgc2NoZWRfc3dpdGNoKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1 Y3QgdA0KIHZvaWQNCiBzY2hlZF93YWtldXAoc3RydWN0IHRocmVhZCAqdGQp DQogew0KKwlzdHJ1Y3QgdGRfc2NoZWQgKnRzOw0KKw0KIAlUSFJFQURfTE9D S19BU1NFUlQodGQsIE1BX09XTkVEKTsNCi0JaWYgKHRkLT50ZF9zbHB0aW1l ID4gMSkgew0KKwl0cyA9IHRkLT50ZF9zY2hlZDsNCisJaWYgKHRzLT50c19z bHB0aW1lID4gMSkgew0KIAkJdXBkYXRlcHJpKHRkKTsNCiAJCXJlc2V0cHJp b3JpdHkodGQpOw0KIAl9DQotCXRkLT50ZF9zbHB0aW1lID0gMDsNCisJdGQt PnRkX3NscHRpY2sgPSB0aWNrczsNCisJdHMtPnRzX3NscHRpbWUgPSAwOw0K IAlzY2hlZF9hZGQodGQsIFNSUV9CT1JJTkcpOw0KIH0NCiANCkluZGV4OiBz eXMva2Vybi9zY2hlZF91bGUuYw0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMDYNCmRpZmYgLXUgLXAgLXIx LjIwNiBzY2hlZF91bGUuYw0KLS0tIHN5cy9rZXJuL3NjaGVkX3VsZS5jCTE3 IFNlcCAyMDA3IDA1OjI3OjIwIC0wMDAwCTEuMjA2DQorKysgc3lzL2tlcm4v c2NoZWRfdWxlLmMJMTcgU2VwIDIwMDcgMDY6MDc6MzAgLTAwMDANCkBAIC04 OCw3ICs4OCw2IEBAIHN0cnVjdCB0ZF9zY2hlZCB7CQ0KIAlzaG9ydAkJdHNf ZmxhZ3M7CS8qIFRTRl8qIGZsYWdzLiAqLw0KIAl1X2NoYXIJCXRzX3JxaW5k ZXg7CS8qIFJ1biBxdWV1ZSBpbmRleC4gKi8NCiAJdV9jaGFyCQl0c19jcHU7 CQkvKiBDUFUgdGhhdCB3ZSBoYXZlIGFmZmluaXR5IGZvci4gKi8NCi0JaW50 CQl0c19zbHB0aWNrOwkvKiBUaWNrIHdoZW4gd2Ugd2VudCB0byBzbGVlcC4g Ki8NCiAJaW50CQl0c19zbGljZTsJLyogVGlja3Mgb2Ygc2xpY2UgcmVtYWlu aW5nLiAqLw0KIAl1X2ludAkJdHNfc2xwdGltZTsJLyogTnVtYmVyIG9mIHRp Y2tzIHdlIHZvbC4gc2xlcHQgKi8NCiAJdV9pbnQJCXRzX3J1bnRpbWU7CS8q IE51bWJlciBvZiB0aWNrcyB3ZSB3ZXJlIHJ1bm5pbmcgKi8NCkBAIC0xOTE0 LDcgKzE5MTMsNyBAQCBzY2hlZF9zbGVlcChzdHJ1Y3QgdGhyZWFkICp0ZCkN CiANCiAJVEhSRUFEX0xPQ0tfQVNTRVJUKHRkLCBNQV9PV05FRCk7DQogDQot CXRkLT50ZF9zY2hlZC0+dHNfc2xwdGljayA9IHRpY2tzOw0KKwl0ZC0+dGRf c2xwdGljayA9IHRpY2tzOw0KIH0NCiANCiAvKg0KQEAgLTE5MzMsOCArMTkz Miw4IEBAIHNjaGVkX3dha2V1cChzdHJ1Y3QgdGhyZWFkICp0ZCkNCiAJICog SWYgd2Ugc2xlcHQgZm9yIG1vcmUgdGhhbiBhIHRpY2sgdXBkYXRlIG91ciBp bnRlcmFjdGl2aXR5IGFuZA0KIAkgKiBwcmlvcml0eS4NCiAJICovDQotCXNs cHRpY2sgPSB0cy0+dHNfc2xwdGljazsNCi0JdHMtPnRzX3NscHRpY2sgPSAw Ow0KKwlzbHB0aWNrID0gdGQtPnRkX3NscHRpY2s7DQorCXRkLT50ZF9zbHB0 aWNrID0gMDsNCiAJaWYgKHNscHRpY2sgJiYgc2xwdGljayAhPSB0aWNrcykg ew0KIAkJdV9pbnQgaHp0aWNrczsNCiANCkBAIC0yNDM1LDcgKzI0MzQsNiBA QCBzY2hlZF9wY3RjcHUoc3RydWN0IHRocmVhZCAqdGQpDQogCQlydGljayA9 IG1pbihTQ0hFRF9USUNLX0haKHRzKSAvIFNDSEVEX1RJQ0tfU0VDUywgaHop Ow0KIAkJcGN0Y3B1ID0gKEZTQ0FMRSAqICgoRlNDQUxFICogcnRpY2spL2h6 KSkgPj4gRlNISUZUOw0KIAl9DQotCXRkLT50ZF9wcm9jLT5wX3N3dGltZSA9 IHRzLT50c19sdGljayAtIHRzLT50c19mdGljazsNCiAJdGhyZWFkX3VubG9j ayh0ZCk7DQogDQogCXJldHVybiAocGN0Y3B1KTsNCkluZGV4OiBzeXMvc3lz L3Byb2MuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9o b21lL25jdnMvc3JjL3N5cy9zeXMvcHJvYy5oLHYNCnJldHJpZXZpbmcgcmV2 aXNpb24gMS40OTANCmRpZmYgLXUgLXAgLXIxLjQ5MCBwcm9jLmgNCi0tLSBz eXMvc3lzL3Byb2MuaAkxNyBTZXAgMjAwNyAwNToyNzoyMSAtMDAwMAkxLjQ5 MA0KKysrIHN5cy9zeXMvcHJvYy5oCTE3IFNlcCAyMDA3IDA2OjAwOjUwIC0w MDAwDQpAQCAtMjQyLDcgKzI0Miw3IEBAIHN0cnVjdCB0aHJlYWQgew0KIAlz dHJ1Y3QgdGhyZWFkCSp0ZF9zdGFuZGluOwkvKiAoayArIGEpIFVzZSB0aGlz IGZvciBhbiB1cGNhbGwuICovDQogCXN0cnVjdCBrc2VfdXBjYWxsICp0ZF91 cGNhbGw7CS8qIChrICsgdCkgVXBjYWxsIHN0cnVjdHVyZS4gKi8NCiAJdV9p bnQJCXRkX2VzdGNwdTsJLyogKHQpIGVzdGltYXRlZCBjcHUgdXRpbGl6YXRp b24gKi8NCi0JdV9pbnQJCXRkX3NscHRpbWU7CS8qICh0KSBIb3cgbG9uZyBj b21wbGV0ZWx5IGJsb2NrZWQuICovDQorCXVfaW50CQl0ZF9zbHB0aWNrOwkv KiAodCkgVGltZSBhdCBzbGVlcC4gKi8NCiAJc3RydWN0IHJ1c2FnZQl0ZF9y dTsJCS8qICh0KSBydXNhZ2UgaW5mb3JtYXRpb24gKi8NCiAJdWludDY0X3QJ dGRfcnVudGltZTsJLyogKHQpIEhvdyBtYW55IGNwdSB0aWNrcyB3ZSd2ZSBy dW4uICovDQogCXVfaW50IAkJdGRfcHRpY2tzOwkvKiAodCkgU3RhdGNsb2Nr IGhpdHMgZm9yIHByb2ZpbGluZyAqLw0KQEAgLTUyMCw3ICs1MjAsNyBAQCBz dHJ1Y3QgcHJvYyB7DQogI2RlZmluZQlwX3N0YXJ0emVybwlwX29wcGlkDQog CXBpZF90CQlwX29wcGlkOwkvKiAoYyArIGUpIFNhdmUgcHBpZCBpbiBwdHJh Y2UuIFhYWCAqLw0KIAlzdHJ1Y3Qgdm1zcGFjZQkqcF92bXNwYWNlOwkvKiAo YikgQWRkcmVzcyBzcGFjZS4gKi8NCi0JdV9pbnQJCXBfc3d0aW1lOwkvKiAo aikgVGltZSBzd2FwcGVkIGluIG9yIG91dC4gKi8NCisJdV9pbnQJCXBfc3d0 aWNrOwkvKiAoaikgVGljayB3aGVuIHN3YXBwZWQgaW4gb3Igb3V0LiAqLw0K IAlzdHJ1Y3QgaXRpbWVydmFsIHBfcmVhbHRpbWVyOwkvKiAoYykgQWxhcm0g dGltZXIuICovDQogCXN0cnVjdCBydXNhZ2UJcF9ydTsJCS8qIChhKSBFeGl0 IGluZm9ybWF0aW9uLiAqLw0KIAlzdHJ1Y3QgcnVzYWdlX2V4dCBwX3J1eDsJ LyogKGNqKSBJbnRlcm5hbCByZXNvdXJjZSB1c2FnZS4gKi8NCkluZGV4OiBz eXMvdm0vdm1fZ2x1ZS5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL3ZtL3ZtX2dsdWUuYyx2DQpyZXRy aWV2aW5nIHJldmlzaW9uIDEuMjI0DQpkaWZmIC11IC1wIC1yMS4yMjQgdm1f Z2x1ZS5jDQotLS0gc3lzL3ZtL3ZtX2dsdWUuYwkxNyBTZXAgMjAwNyAwNToy NzoyMSAtMDAwMAkxLjIyNA0KKysrIHN5cy92bS92bV9nbHVlLmMJMTcgU2Vw IDIwMDcgMDY6MDU6MDcgLTAwMDANCkBAIC02MzYsNyArNjM2LDcgQEAgZmF1 bHRpbihwKQ0KIAkJUFJPQ19MT0NLKHApOw0KIAkJUFJPQ19TTE9DSyhwKTsN CiAJCXN3YXBjbGVhcihwKTsNCi0JCXAtPnBfc3d0aW1lID0gMDsNCisJCXAt PnBfc3d0aWNrID0gdGlja3M7DQogCQlQUk9DX1NVTkxPQ0socCk7DQogDQog CQl3YWtldXAoJnAtPnBfZmxhZyk7DQpAQCAtNjYzLDkgKzY2MywxMSBAQCBz Y2hlZHVsZXIoZHVtbXkpDQogew0KIAlzdHJ1Y3QgcHJvYyAqcDsNCiAJc3Ry dWN0IHRocmVhZCAqdGQ7DQotCWludCBwcmk7DQogCXN0cnVjdCBwcm9jICpw cDsNCisJaW50IHNscHRpbWU7DQorCWludCBzd3RpbWU7DQogCWludCBwcHJp Ow0KKwlpbnQgcHJpOw0KIA0KIAltdHhfYXNzZXJ0KCZHaWFudCwgTUFfT1dO RUQgfCBNQV9OT1RSRUNVUlNFRCk7DQogCW10eF91bmxvY2soJkdpYW50KTsN CkBAIC02ODgsNiArNjkwLDcgQEAgbG9vcDoNCiAJCQlQUk9DX1VOTE9DSyhw KTsNCiAJCQljb250aW51ZTsNCiAJCX0NCisJCXN3dGltZSA9ICh0aWNrcyAt IHAtPnBfc3d0aWNrKSAvIGh6Ow0KIAkJUFJPQ19TTE9DSyhwKTsNCiAJCUZP UkVBQ0hfVEhSRUFEX0lOX1BST0MocCwgdGQpIHsNCiAJCQkvKg0KQEAgLTY5 Nyw3ICs3MDAsOCBAQCBsb29wOg0KIAkJCSAqLw0KIAkJCXRocmVhZF9sb2Nr KHRkKTsNCiAJCQlpZiAodGQtPnRkX2luaGliaXRvcnMgPT0gVERJX1NXQVBQ RUQpIHsNCi0JCQkJcHJpID0gcC0+cF9zd3RpbWUgKyB0ZC0+dGRfc2xwdGlt ZTsNCisJCQkJc2xwdGltZSA9ICh0aWNrcyAtIHRkLT50ZF9zbHB0aWNrKSAv IGh6Ow0KKwkJCQlwcmkgPSBzd3RpbWUgKyBzbHB0aW1lOw0KIAkJCQlpZiAo KHRkLT50ZF9mbGFncyAmIFRERl9TV0FQSU5SRVEpID09IDApDQogCQkJCQlw cmkgLT0gcC0+cF9uaWNlICogODsNCiAJCQkJLyoNCkBAIC04MTYsNiArODIw LDcgQEAgcmV0cnk6DQogCUZPUkVBQ0hfUFJPQ19JTl9TWVNURU0ocCkgew0K IAkJc3RydWN0IHZtc3BhY2UgKnZtOw0KIAkJaW50IG1pbnNscHRpbWUgPSAx MDAwMDA7DQorCQlpbnQgc2xwdGltZTsNCiAJCQ0KIAkJLyoNCiAJCSAqIFdh dGNoIG91dCBmb3IgYSBwcm9jZXNzIGluDQpAQCAtODgyLDEyICs4ODcsMTIg QEAgcmV0cnk6DQogCQkJCQl0aHJlYWRfdW5sb2NrKHRkKTsNCiAJCQkJCWdv dG8gbmV4dHByb2M7DQogCQkJCX0NCi0NCisJCQkJc2xwdGltZSA9ICh0aWNr cyAtIHRkLT50ZF9zbHB0aWNrKSAvIGh6Ow0KIAkJCQkvKg0KIAkJCQkgKiBH dWFyYW50ZWUgc3dhcF9pZGxlX3RocmVzaG9sZDENCiAJCQkJICogdGltZSBp biBtZW1vcnkuDQogCQkJCSAqLw0KLQkJCQlpZiAodGQtPnRkX3NscHRpbWUg PCBzd2FwX2lkbGVfdGhyZXNob2xkMSkgew0KKwkJCQlpZiAoc2xwdGltZSA8 IHN3YXBfaWRsZV90aHJlc2hvbGQxKSB7DQogCQkJCQl0aHJlYWRfdW5sb2Nr KHRkKTsNCiAJCQkJCWdvdG8gbmV4dHByb2M7DQogCQkJCX0NCkBAIC05MTQs MTMgKzkxOSwxMyBAQCByZXRyeToNCiAJCQkJICovDQogCQkJCWlmICgoKGFj dGlvbiAmIFZNX1NXQVBfTk9STUFMKSA9PSAwKSAmJg0KIAkJCQkgICAgKCgo YWN0aW9uICYgVk1fU1dBUF9JRExFKSA9PSAwKSB8fA0KLQkJCQkgICAgKHRk LT50ZF9zbHB0aW1lIDwgc3dhcF9pZGxlX3RocmVzaG9sZDIpKSkgew0KKwkJ CQkgICAgKHNscHRpbWUgPCBzd2FwX2lkbGVfdGhyZXNob2xkMikpKSB7DQog CQkJCQl0aHJlYWRfdW5sb2NrKHRkKTsNCiAJCQkJCWdvdG8gbmV4dHByb2M7 DQogCQkJCX0NCiANCi0JCQkJaWYgKG1pbnNscHRpbWUgPiB0ZC0+dGRfc2xw dGltZSkNCi0JCQkJCW1pbnNscHRpbWUgPSB0ZC0+dGRfc2xwdGltZTsNCisJ CQkJaWYgKG1pbnNscHRpbWUgPiBzbHB0aW1lKQ0KKwkJCQkJbWluc2xwdGlt ZSA9IHNscHRpbWU7DQogCQkJCXRocmVhZF91bmxvY2sodGQpOw0KIAkJCX0N CiANCkBAIC0xMDM4LDcgKzEwNDMsNyBAQCBzd2Fwb3V0KHApDQogCVBST0Nf TE9DSyhwKTsNCiAJcC0+cF9mbGFnICY9IH5QX1NXQVBQSU5HT1VUOw0KIAlQ Uk9DX1NMT0NLKHApOw0KLQlwLT5wX3N3dGltZSA9IDA7DQorCXAtPnBfc3d0 aWNrID0gdGlja3M7DQogCXJldHVybiAoMCk7DQogfQ0KICNlbmRpZiAvKiAh Tk9fU1dBUFBJTkcgKi8NCg== --0-2003406049-1190073957=:558-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 04:33:57 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BD2216A418 for ; Tue, 18 Sep 2007 04:33:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id D0DA013C459 for ; Tue, 18 Sep 2007 04:33:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IXUmJ-000Oqv-AT for arch@freebsd.org; Tue, 18 Sep 2007 07:33:47 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8I4Xa05086167; Tue, 18 Sep 2007 07:33:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8I4XZ1w086166; Tue, 18 Sep 2007 07:33:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Sep 2007 07:33:35 +0300 From: Kostik Belousov To: Jeff Roberson Message-ID: <20070918043335.GR79542@deviant.kiev.zoral.com.ua> References: <20070917165657.B558@10.0.0.1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kAOhhqH5290wydqT" Content-Disposition: inline In-Reply-To: <20070917165657.B558@10.0.0.1> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 362d5034abbfed611c52a2913ea5ff69 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1485 [September 17 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: arch@freebsd.org Subject: Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 04:33:57 -0000 --kAOhhqH5290wydqT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2007 at 05:05:57PM -0700, Jeff Roberson wrote: > Enclosed is a patch that fixes swapping with ULE. ULE has never properly= =20 > set p_swtime and td_slptime which are used by the swapout/swapin code to= =20 > select the appropriate thread to swap. >=20 > In 4BSD these two variables are increment once per-second as schedcpu()= =20 > iterates over all threads. ULE does not have a once per-second loop=20 > iterating over all threads. So I have changed p_swtime to p_swtick and= =20 > td_slptime to td_slptick. These record the value of 'ticks' when the=20 > thread slept or was last swapped in or out. >=20 > For backwards compatibility I leave the values in kinfo_proc with the=20 > legacy meaning by subtracting from ticks and dividing by hz. I perform a= =20 > similar transformation in the swapout code to convert to seconds. This= =20 > change does make it possible to use sub-second granular decisions in the= =20 > swap code, however I'm not sure if that's really necessary. >=20 > So that I did not disturb the 4BSD mechanism I kept the original=20 > td_slptime in the td_sched area. It should be possible to use td_slptick= =20 > directly but especially this close to release I did not want to change=20 > 4BSD. >=20 > Feedback and testing welcome. Purely cosmetic request: please make the ticks and hz variables in the libkvm/kvm_proc.c static. Or, even better, move it into the struct __kvm. --kAOhhqH5290wydqT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG71UeC3+MBN1Mb4gRAhVLAJ4o2OWJfJJhUKRmIyGwrBArUvjO1wCguCF2 W1KjYYG1qcDbpc5l82GZBTE= =4GbX -----END PGP SIGNATURE----- --kAOhhqH5290wydqT-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 05:48:52 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F30A16A41A for ; Tue, 18 Sep 2007 05:48:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0C44613C45E for ; Tue, 18 Sep 2007 05:48:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 17 Sep 2007 22:38:22 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id DF7831263F4; Mon, 17 Sep 2007 22:38:21 -0700 (PDT) Message-ID: <46EF644E.9050207@elischer.org> Date: Mon, 17 Sep 2007 22:38:22 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jeff Roberson References: <20070917165657.B558@10.0.0.1> In-Reply-To: <20070917165657.B558@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 05:48:52 -0000 Jeff Roberson wrote: > Enclosed is a patch that fixes swapping with ULE. ULE has never > properly set p_swtime and td_slptime which are used by the > swapout/swapin code to select the appropriate thread to swap. I have not looked at in the depth required, but 2 points that I was unable to check to my satisfaction before I got called away for work.... 1/ the source of the ticks is a monotonically increasing count that never goes backwards or changes? 2/ nothing that used to be accounted in seconds becomes accounted for in ticks? > > In 4BSD these two variables are increment once per-second as schedcpu() > iterates over all threads. ULE does not have a once per-second loop > iterating over all threads. So I have changed p_swtime to p_swtick and > td_slptime to td_slptick. These record the value of 'ticks' when the > thread slept or was last swapped in or out. > > For backwards compatibility I leave the values in kinfo_proc with the > legacy meaning by subtracting from ticks and dividing by hz. I perform > a similar transformation in the swapout code to convert to seconds. > This change does make it possible to use sub-second granular decisions > in the swap code, however I'm not sure if that's really necessary. > > So that I did not disturb the 4BSD mechanism I kept the original > td_slptime in the td_sched area. It should be possible to use > td_slptick directly but especially this close to release I did not want > to change 4BSD. > > Feedback and testing welcome. > > Thanks, > Jeff > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 08:23:25 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D27D16A419 for ; Tue, 18 Sep 2007 08:23:25 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id B34F113C467 for ; Tue, 18 Sep 2007 08:23:24 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8I8Mw5i049790 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 04:22:59 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 01:25:52 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Kostik Belousov In-Reply-To: <20070918043335.GR79542@deviant.kiev.zoral.com.ua> Message-ID: <20070918012543.Y558@10.0.0.1> References: <20070917165657.B558@10.0.0.1> <20070918043335.GR79542@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 08:23:25 -0000 On Tue, 18 Sep 2007, Kostik Belousov wrote: > On Mon, Sep 17, 2007 at 05:05:57PM -0700, Jeff Roberson wrote: >> Enclosed is a patch that fixes swapping with ULE. ULE has never properly >> set p_swtime and td_slptime which are used by the swapout/swapin code to >> select the appropriate thread to swap. >> >> In 4BSD these two variables are increment once per-second as schedcpu() >> iterates over all threads. ULE does not have a once per-second loop >> iterating over all threads. So I have changed p_swtime to p_swtick and >> td_slptime to td_slptick. These record the value of 'ticks' when the >> thread slept or was last swapped in or out. >> >> For backwards compatibility I leave the values in kinfo_proc with the >> legacy meaning by subtracting from ticks and dividing by hz. I perform a >> similar transformation in the swapout code to convert to seconds. This >> change does make it possible to use sub-second granular decisions in the >> swap code, however I'm not sure if that's really necessary. >> >> So that I did not disturb the 4BSD mechanism I kept the original >> td_slptime in the td_sched area. It should be possible to use td_slptick >> directly but especially this close to release I did not want to change >> 4BSD. >> >> Feedback and testing welcome. > > Purely cosmetic request: please make the ticks and hz variables in the > libkvm/kvm_proc.c static. Or, even better, move it into the struct __kvm. > Thanks, will do. Jeff From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 08:26:05 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B50FB16A417 for ; Tue, 18 Sep 2007 08:26:05 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 68C5A13C491 for ; Tue, 18 Sep 2007 08:26:05 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8I8PXC4049976 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 04:25:35 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 01:28:27 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Julian Elischer In-Reply-To: <46EF644E.9050207@elischer.org> Message-ID: <20070918012555.G558@10.0.0.1> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 08:26:05 -0000 On Mon, 17 Sep 2007, Julian Elischer wrote: > Jeff Roberson wrote: >> Enclosed is a patch that fixes swapping with ULE. ULE has never properly >> set p_swtime and td_slptime which are used by the swapout/swapin code to >> select the appropriate thread to swap. > > I have not looked at in the depth required, but 2 points that I was unable > to check to my satisfaction before I got called away for work.... > > 1/ the source of the ticks is a monotonically increasing count that never > goes backwards or changes? ticks is incremented each time hardclock() is called. That's it. > > 2/ nothing that used to be accounted in seconds becomes accounted for in > ticks? I scale back to seconds where it is required. Really I think ticks would be the better metric in vm_glue.c but didn't want to make any drastic changes. Thanks, Jeff > > >> >> In 4BSD these two variables are increment once per-second as schedcpu() >> iterates over all threads. ULE does not have a once per-second loop >> iterating over all threads. So I have changed p_swtime to p_swtick and >> td_slptime to td_slptick. These record the value of 'ticks' when the >> thread slept or was last swapped in or out. >> >> For backwards compatibility I leave the values in kinfo_proc with the >> legacy meaning by subtracting from ticks and dividing by hz. I perform a >> similar transformation in the swapout code to convert to seconds. This >> change does make it possible to use sub-second granular decisions in the >> swap code, however I'm not sure if that's really necessary. >> >> So that I did not disturb the 4BSD mechanism I kept the original td_slptime >> in the td_sched area. It should be possible to use td_slptick directly but >> especially this close to release I did not want to change 4BSD. >> >> Feedback and testing welcome. >> >> Thanks, >> Jeff >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 15:12:26 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9EA616A421; Tue, 18 Sep 2007 15:12:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5B20513C457; Tue, 18 Sep 2007 15:12:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l8IFCCpA013882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 01:12:12 +1000 Date: Wed, 19 Sep 2007 01:12:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Joe Marcus Clarke In-Reply-To: <1189629164.80084.81.camel@shumai.marcuscom.com> Message-ID: <20070919005425.P75789@besplex.bde.org> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl> <1188660782.41727.5.camel@shumai.marcuscom.com> <20070901224025.GA97796@stack.nl> <20070902131910.H46281@delplex.bde.org> <1189629164.80084.81.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 15:12:26 -0000 On Wed, 12 Sep 2007, Joe Marcus Clarke wrote: Sorry this reply took so long. > On Sun, 2007-09-02 at 14:17 +1000, Bruce Evans wrote: >>> From Jilles' previous reply: >>>>> The fixed version would then be >>>>> >>>>> error = tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0); >> >> I think this is right. The kernel should never loop on ERESTART like this. >> Please fix the remaining style bug in it (missing spaces around binary >> operator). > > Bruce, I didn't know if you saw my fix, if it needs more work, or if > you're going to commit it? I'd really like to get this fixed before > 7.0. Should I open a PR to track it? Thanks. > > http://www.marcuscom.com/downloads/syscons.c.diff > http://www.marcuscom.com/downloads/pcvt_ext.c (-STABLE only) I saw a new style bug in it, but wasn't going to complain. Now I will :-). % --- src/sys/dev/syscons/syscons.c.orig 2007-09-02 23:04:15.000000000 -0400 % +++ src/sys/dev/syscons/syscons.c 2007-09-02 23:05:06.000000000 -0400 % @@ -1073,8 +1073,7 @@ scioctl(struct cdev *dev, u_long cmd, ca % scp = sc_get_stat(SC_DEV(sc, i)); % if (scp == scp->sc->cur_scp) % return 0; % - while ((error=tsleep(&scp->smode, PZERO|PCATCH, % - "waitvt", 0)) == ERESTART) ; % + error = tsleep(&scp->smode, (PZERO|PCATCH), "waitvt", 0); % return error; % % case VT_GETACTIVE: /* get active vty # */ It now has extra parentheses, and still doesn't have spaces around the binary operator. In pcvt_ext.c.diff, the changes are larger and I only glanced at most of them, but noticed that the formatting of the `PZERO | PCATCH' are was already what I want but was changed to the above (2 changes instead of 1). pcvt is almost dead and its style so unusual that it is difficult to be bug for bug compatible with, so I would try to avoid making any style changes in it. Please commit all the changes, preferably after fixing the style bugs. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 15:13:14 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B081316A477 for ; Tue, 18 Sep 2007 15:13:14 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2505813C4D3 for ; Tue, 18 Sep 2007 15:13:13 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 43866 invoked from network); 18 Sep 2007 14:31:15 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Sep 2007 14:31:15 -0000 Message-ID: <46EFE4BD.4030505@freebsd.org> Date: Tue, 18 Sep 2007 16:46:21 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Jeff Roberson References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> In-Reply-To: <20070918012555.G558@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Julian Elischer Subject: Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 15:13:14 -0000 Jeff Roberson wrote: > On Mon, 17 Sep 2007, Julian Elischer wrote: > >> Jeff Roberson wrote: >>> Enclosed is a patch that fixes swapping with ULE. ULE has never >>> properly set p_swtime and td_slptime which are used by the >>> swapout/swapin code to select the appropriate thread to swap. >> >> I have not looked at in the depth required, but 2 points that I was >> unable >> to check to my satisfaction before I got called away for work.... >> >> 1/ the source of the ticks is a monotonically increasing count that never >> goes backwards or changes? > > ticks is incremented each time hardclock() is called. That's it. > >> >> 2/ nothing that used to be accounted in seconds becomes accounted for >> in ticks? > > I scale back to seconds where it is required. Really I think ticks > would be the better metric in vm_glue.c but didn't want to make any > drastic changes. ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable short uptime. You have to make sure that your code handles that correctly or you run into lots of strange effects which are almost impossible to reproduce. In TCP we've got bitten by that. -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 15:52:49 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D90E916A473 for ; Tue, 18 Sep 2007 15:52:49 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 75BFA13C4D9 for ; Tue, 18 Sep 2007 15:52:49 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.1/8.14.1) with ESMTP id l8IFrhMs032675; Tue, 18 Sep 2007 11:53:43 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Bruce Evans In-Reply-To: <20070919005425.P75789@besplex.bde.org> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl> <1188660782.41727.5.camel@shumai.marcuscom.com> <20070901224025.GA97796@stack.nl> <20070902131910.H46281@delplex.bde.org> <1189629164.80084.81.camel@shumai.marcuscom.com> <20070919005425.P75789@besplex.bde.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0dEr8OhQVqYnZmhO7Pqb" Organization: FreeBSD, Inc. Date: Tue, 18 Sep 2007 11:52:42 -0400 Message-Id: <1190130762.48257.1.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 15:52:50 -0000 --=-0dEr8OhQVqYnZmhO7Pqb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-09-19 at 01:12 +1000, Bruce Evans wrote: > On Wed, 12 Sep 2007, Joe Marcus Clarke wrote: >=20 > Sorry this reply took so long. >=20 > > On Sun, 2007-09-02 at 14:17 +1000, Bruce Evans wrote: > >>> From Jilles' previous reply: > >>>>> The fixed version would then be > >>>>> > >>>>> error =3D tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0); > >> > >> I think this is right. The kernel should never loop on ERESTART like = this. > >> Please fix the remaining style bug in it (missing spaces around binary > >> operator). > > > > Bruce, I didn't know if you saw my fix, if it needs more work, or if > > you're going to commit it? I'd really like to get this fixed before > > 7.0. Should I open a PR to track it? Thanks. > > > > http://www.marcuscom.com/downloads/syscons.c.diff > > http://www.marcuscom.com/downloads/pcvt_ext.c (-STABLE only) >=20 > I saw a new style bug in it, but wasn't going to complain. Now I will :-= ). >=20 > % --- src/sys/dev/syscons/syscons.c.orig 2007-09-02 23:04:15.000000000 -0= 400 > % +++ src/sys/dev/syscons/syscons.c 2007-09-02 23:05:06.000000000 -0400 > % @@ -1073,8 +1073,7 @@ scioctl(struct cdev *dev, u_long cmd, ca > % scp =3D sc_get_stat(SC_DEV(sc, i)); > % if (scp =3D=3D scp->sc->cur_scp) > % return 0; > % - while ((error=3Dtsleep(&scp->smode, PZERO|PCATCH, > % - "waitvt", 0)) =3D=3D ERESTART) ; > % + error =3D tsleep(&scp->smode, (PZERO|PCATCH), "waitvt", 0); > % return error; > %=20 > % case VT_GETACTIVE: /* get active vty # */ >=20 > It now has extra parentheses, and still doesn't have spaces around the > binary operator. I re-read your first email twice, and read it as "put parentheses around the binary operator" both times. Sorry for being so dense. A space makes more sense. >=20 > In pcvt_ext.c.diff, the changes are larger and I only glanced at most > of them, but noticed that the formatting of the `PZERO | PCATCH' are > was already what I want but was changed to the above (2 changes instead > of 1). pcvt is almost dead and its style so unusual that it is difficult > to be bug for bug compatible with, so I would try to avoid making any > style changes in it. >=20 > Please commit all the changes, preferably after fixing the style bugs. Thanks, will do after approval from re. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-0dEr8OhQVqYnZmhO7Pqb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG7/RGb2iPiv4Uz4cRAnfbAJ91WuNZrMk2V1df4QsFGf34qBHQDwCePc/c K1eZvfCXS1uI6rIABAhAm+8= =Z+O2 -----END PGP SIGNATURE----- --=-0dEr8OhQVqYnZmhO7Pqb-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 21:20:15 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05DC616A469; Tue, 18 Sep 2007 21:20:15 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id BA7AC13C45D; Tue, 18 Sep 2007 21:20:14 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8ILK62s053766 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 17:20:07 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 14:22:58 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Andre Oppermann In-Reply-To: <46EFE4BD.4030505@freebsd.org> Message-ID: <20070918142115.C558@10.0.0.1> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Julian Elischer Subject: Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 21:20:15 -0000 On Tue, 18 Sep 2007, Andre Oppermann wrote: > Jeff Roberson wrote: >> On Mon, 17 Sep 2007, Julian Elischer wrote: >> >>> Jeff Roberson wrote: >>>> Enclosed is a patch that fixes swapping with ULE. ULE has never properly >>>> set p_swtime and td_slptime which are used by the swapout/swapin code to >>>> select the appropriate thread to swap. >>> >>> I have not looked at in the depth required, but 2 points that I was unable >>> to check to my satisfaction before I got called away for work.... >>> >>> 1/ the source of the ticks is a monotonically increasing count that never >>> goes backwards or changes? >> >> ticks is incremented each time hardclock() is called. That's it. >> >>> >>> 2/ nothing that used to be accounted in seconds becomes accounted for in >>> ticks? >> >> I scale back to seconds where it is required. Really I think ticks would >> be the better metric in vm_glue.c but didn't want to make any drastic >> changes. > > ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable > short uptime. You have to make sure that your code handles that > correctly or you run into lots of strange effects which are almost > impossible to reproduce. In TCP we've got bitten by that. Thanks Andre, this is a good point. For the td_slptime I don't think it's of practical concern. However, for swtime I think I will convert it then to seconds from boot. Jeff > > -- > Andre > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 22:34:29 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E0D516A41A; Tue, 18 Sep 2007 22:34:29 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4842013C428; Tue, 18 Sep 2007 22:34:29 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8IMYMLK071214 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 18:34:23 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 15:37:14 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Andre Oppermann In-Reply-To: <20070918142115.C558@10.0.0.1> Message-ID: <20070918153536.D558@10.0.0.1> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Julian Elischer Subject: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 22:34:29 -0000 On Tue, 18 Sep 2007, Jeff Roberson wrote: > On Tue, 18 Sep 2007, Andre Oppermann wrote: > >> Jeff Roberson wrote: >>> On Mon, 17 Sep 2007, Julian Elischer wrote: >>> >>>> Jeff Roberson wrote: >>>>> Enclosed is a patch that fixes swapping with ULE. ULE has never >>>>> properly set p_swtime and td_slptime which are used by the >>>>> swapout/swapin code to select the appropriate thread to swap. >>>> >>>> I have not looked at in the depth required, but 2 points that I was >>>> unable >>>> to check to my satisfaction before I got called away for work.... >>>> >>>> 1/ the source of the ticks is a monotonically increasing count that never >>>> goes backwards or changes? >>> >>> ticks is incremented each time hardclock() is called. That's it. >>> >>>> >>>> 2/ nothing that used to be accounted in seconds becomes accounted for in >>>> ticks? >>> >>> I scale back to seconds where it is required. Really I think ticks would >>> be the better metric in vm_glue.c but didn't want to make any drastic >>> changes. >> >> ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable >> short uptime. You have to make sure that your code handles that >> correctly or you run into lots of strange effects which are almost >> impossible to reproduce. In TCP we've got bitten by that. > > Thanks Andre, this is a good point. For the td_slptime I don't think it's of > practical concern. However, for swtime I think I will convert it then to > seconds from boot. Is there a good reason for not making ticks 64bit? math involving this value is relatively infrequent. Bruce? Any comments? It'd sure let us forget all of these counter wrapping problems. Thanks, Jeff > > Jeff > >> >> -- >> Andre >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 23:55:26 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6711116A584 for ; Tue, 18 Sep 2007 23:55:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 1609D13C457 for ; Tue, 18 Sep 2007 23:55:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 18 Sep 2007 16:55:25 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id DB37C12641B; Tue, 18 Sep 2007 16:55:23 -0700 (PDT) Message-ID: <46F0656A.7030802@elischer.org> Date: Tue, 18 Sep 2007 16:55:22 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Sam Leffler References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <20070918153536.D558@10.0.0.1> <46F05F88.5060809@errno.com> In-Reply-To: <46F05F88.5060809@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Oppermann , arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 23:55:26 -0000 Sam Leffler wrote: > Jeff Roberson wrote: >> On Tue, 18 Sep 2007, Jeff Roberson wrote: >> >>> On Tue, 18 Sep 2007, Andre Oppermann wrote: >>> >>>> Jeff Roberson wrote: >>>>> On Mon, 17 Sep 2007, Julian Elischer wrote: >>>>> >>>>>> Jeff Roberson wrote: >>>>>>> Enclosed is a patch that fixes swapping with ULE. ULE has never >>>>>>> properly set p_swtime and td_slptime which are used by the >>>>>>> swapout/swapin code to select the appropriate thread to swap. >>>>>> >>>>>> I have not looked at in the depth required, but 2 points that I >>>>>> was unable >>>>>> to check to my satisfaction before I got called away for work.... >>>>>> >>>>>> 1/ the source of the ticks is a monotonically increasing count >>>>>> that never >>>>>> goes backwards or changes? >>>>> >>>>> ticks is incremented each time hardclock() is called. That's it. >>>>> >>>>>> >>>>>> 2/ nothing that used to be accounted in seconds becomes accounted >>>>>> for in ticks? >>>>> >>>>> I scale back to seconds where it is required. Really I think ticks >>>>> would be the better metric in vm_glue.c but didn't want to make any >>>>> drastic changes. >>>> >>>> ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable >>>> short uptime. You have to make sure that your code handles that >>>> correctly or you run into lots of strange effects which are almost >>>> impossible to reproduce. In TCP we've got bitten by that. >>> >>> Thanks Andre, this is a good point. For the td_slptime I don't think >>> it's of practical concern. However, for swtime I think I will >>> convert it then to seconds from boot. >> >> Is there a good reason for not making ticks 64bit? math involving >> this value is relatively infrequent. Bruce? Any comments? It'd sure >> let us forget all of these counter wrapping problems. > > ticks is used a lot. I'd rather set hz back to 100 by default. This > approach is a perfect example of ignoring low-end platforms. but it still needs to work on systems with high hz values. > > Sam From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 00:09:07 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F269C16A41A; Wed, 19 Sep 2007 00:09:06 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id A327413C4B3; Wed, 19 Sep 2007 00:09:06 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8J07dkW093402 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 20:07:40 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 17:10:31 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Sam Leffler In-Reply-To: <46F05F88.5060809@errno.com> Message-ID: <20070918170545.X558@10.0.0.1> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <20070918153536.D558@10.0.0.1> <46F05F88.5060809@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Andre Oppermann , Julian Elischer Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 00:09:07 -0000 On Tue, 18 Sep 2007, Sam Leffler wrote: > Jeff Roberson wrote: >> On Tue, 18 Sep 2007, Jeff Roberson wrote: >> >>> On Tue, 18 Sep 2007, Andre Oppermann wrote: >>> >>>> Jeff Roberson wrote: >>>>> On Mon, 17 Sep 2007, Julian Elischer wrote: >>>>> >>>>>> Jeff Roberson wrote: >>>>>>> Enclosed is a patch that fixes swapping with ULE. ULE has never >>>>>>> properly set p_swtime and td_slptime which are used by the >>>>>>> swapout/swapin code to select the appropriate thread to swap. >>>>>> >>>>>> I have not looked at in the depth required, but 2 points that I was >>>>>> unable >>>>>> to check to my satisfaction before I got called away for work.... >>>>>> >>>>>> 1/ the source of the ticks is a monotonically increasing count that >>>>>> never >>>>>> goes backwards or changes? >>>>> >>>>> ticks is incremented each time hardclock() is called. That's it. >>>>> >>>>>> >>>>>> 2/ nothing that used to be accounted in seconds becomes accounted for >>>>>> in ticks? >>>>> >>>>> I scale back to seconds where it is required. Really I think ticks >>>>> would be the better metric in vm_glue.c but didn't want to make any >>>>> drastic changes. >>>> >>>> ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable >>>> short uptime. You have to make sure that your code handles that >>>> correctly or you run into lots of strange effects which are almost >>>> impossible to reproduce. In TCP we've got bitten by that. >>> >>> Thanks Andre, this is a good point. For the td_slptime I don't think it's >>> of practical concern. However, for swtime I think I will convert it then >>> to seconds from boot. >> >> Is there a good reason for not making ticks 64bit? math involving this >> value is relatively infrequent. Bruce? Any comments? It'd sure let us >> forget all of these counter wrapping problems. > > ticks is used a lot. I'd rather set hz back to 100 by default. This > approach is a perfect example of ignoring low-end platforms. Well there are certainly competing design goals and tradeoffs must be made. In this particular case, I did consider the impact to 32bit platforms. However, many people looking at real-time like platforms want even higher hz, so the solution must scale to both ends. I believe we rarely do division or multiplication of ticks. Emulated 64bit adds and loads are not that expensive. In fact, I don't see any division in kern/. Perhaps you could try it on one of your embedded platforms and see if there is a measurable difference? I suspect there will not be any. Thanks, Jeff > > Sam > From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 00:33:49 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB3FC16A41A for ; Wed, 19 Sep 2007 00:33:49 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 59A3413C428 for ; Wed, 19 Sep 2007 00:33:49 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l8INUGaf029610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 16:30:16 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46F05F88.5060809@errno.com> Date: Tue, 18 Sep 2007 16:30:16 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Jeff Roberson References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <20070918153536.D558@10.0.0.1> In-Reply-To: <20070918153536.D558@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: arch@freebsd.org, Andre Oppermann , Julian Elischer Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 00:33:49 -0000 Jeff Roberson wrote: > On Tue, 18 Sep 2007, Jeff Roberson wrote: > >> On Tue, 18 Sep 2007, Andre Oppermann wrote: >> >>> Jeff Roberson wrote: >>>> On Mon, 17 Sep 2007, Julian Elischer wrote: >>>> >>>>> Jeff Roberson wrote: >>>>>> Enclosed is a patch that fixes swapping with ULE. ULE has never >>>>>> properly set p_swtime and td_slptime which are used by the >>>>>> swapout/swapin code to select the appropriate thread to swap. >>>>> >>>>> I have not looked at in the depth required, but 2 points that I >>>>> was unable >>>>> to check to my satisfaction before I got called away for work.... >>>>> >>>>> 1/ the source of the ticks is a monotonically increasing count >>>>> that never >>>>> goes backwards or changes? >>>> >>>> ticks is incremented each time hardclock() is called. That's it. >>>> >>>>> >>>>> 2/ nothing that used to be accounted in seconds becomes accounted >>>>> for in ticks? >>>> >>>> I scale back to seconds where it is required. Really I think ticks >>>> would be the better metric in vm_glue.c but didn't want to make any >>>> drastic changes. >>> >>> ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable >>> short uptime. You have to make sure that your code handles that >>> correctly or you run into lots of strange effects which are almost >>> impossible to reproduce. In TCP we've got bitten by that. >> >> Thanks Andre, this is a good point. For the td_slptime I don't think >> it's of practical concern. However, for swtime I think I will >> convert it then to seconds from boot. > > Is there a good reason for not making ticks 64bit? math involving > this value is relatively infrequent. Bruce? Any comments? It'd sure > let us forget all of these counter wrapping problems. ticks is used a lot. I'd rather set hz back to 100 by default. This approach is a perfect example of ignoring low-end platforms. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 02:03:37 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0F216A417 for ; Wed, 19 Sep 2007 02:03:37 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id C33E913C468 for ; Wed, 19 Sep 2007 02:03:36 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so40287wxd for ; Tue, 18 Sep 2007 19:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SjvkgN6Q2kqJE1T/grPhssyhWYb/ntST6H7T1fha1OY=; b=eZ8Kv0mh+Ldshp+V8D+FF9QyHb6+AEIU65kKD5wc1RCFLziluLH/tm22npn7GACF/DG5CIjY6/UAOteXvXsE5prW6433xqm2POlYbgVhBw0IfYVtTz1rv8PWNLZCYfEcSXsV9s8LMy3cNL3psqfBV4kkWqqhIzZNSkFUCU+Hxvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dsbZEumKYqqaqbSzFv08xcpoMhf/K24jVobASCc8lM62ry/ntwJLyG+DWVvvarXSuEPPGN7A8XgCoaD/TFAmYZ7vZsb4vwcTumWBBGs/u5epKcWzOPE/N5tyQL+RVoRhCKjru+Eo3k7BxFP1EEiJh/G9Z3YSwSYqZXc6Y1+ulDM= Received: by 10.90.95.11 with SMTP id s11mr128436agb.1190165734431; Tue, 18 Sep 2007 18:35:34 -0700 (PDT) Received: by 10.90.78.14 with HTTP; Tue, 18 Sep 2007 18:35:34 -0700 (PDT) Message-ID: Date: Tue, 18 Sep 2007 21:35:34 -0400 From: "Constantine A. Murenin" To: "Sam Leffler" In-Reply-To: <46F05F88.5060809@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <20070918153536.D558@10.0.0.1> <46F05F88.5060809@errno.com> Cc: Andre Oppermann , Julian Elischer , arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:03:37 -0000 On 18/09/2007, Sam Leffler wrote: > ticks is used a lot. I'd rather set hz back to 100 by default. This > approach is a perfect example of ignoring low-end platforms. Not only that, but it also consumes more power even on the fast platforms. Compare the idle power consumption of my Core 2 Duo Allendale box: kern.hz=100: 72W kern.hz=1000: 74W C. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 02:13:49 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAE116A420 for ; Wed, 19 Sep 2007 02:13:49 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id C9E3813C4B6 for ; Wed, 19 Sep 2007 02:13:48 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.13.8/8.13.8) with ESMTP id l8J1hJmc074277; Tue, 18 Sep 2007 21:43:19 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.13.8/8.13.8/Submit) id l8J1hJKA074148; Tue, 18 Sep 2007 21:43:19 -0400 (EDT) (envelope-from wollman) Date: Tue, 18 Sep 2007 21:43:19 -0400 (EDT) From: Garrett Wollman Message-Id: <200709190143.l8J1hJKA074148@hergotha.csail.mit.edu> To: jroberson@chesapeake.net In-Reply-To: <20070918153536.D558@10.0.0.1> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> Organization: None X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 18 Sep 2007 21:43:19 -0400 (EDT) X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS autolearn=disabled version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on hergotha.csail.mit.edu Cc: , arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:13:49 -0000 Jeff Roberson writes: >Is there a good reason for not making ticks 64bit? math involving this >value is relatively infrequent. Bruce? Any comments? It'd sure let us >forget all of these counter wrapping problems. Making ticks 64 bits on 32-bit architectures means that updates to it will not be atomic. -GAWollman -- Garrett A. Wollman | The real tragedy of human existence is not that we are wollman@csail.mit.edu| nasty by nature, but that a cruel structural asymmetry Opinions not those | grants to rare events of meanness such power to shape of MIT or CSAIL. | our history. - S.J. Gould, Ten Thousand Acts of Kindness From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 02:15:17 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A9C516A41B for ; Wed, 19 Sep 2007 02:15:17 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3263813C483 for ; Wed, 19 Sep 2007 02:15:17 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8J2FDlM024012 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 22:15:16 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 19:18:05 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Garrett Wollman In-Reply-To: <200709190143.l8J1hJKA074148@hergotha.csail.mit.edu> Message-ID: <20070918191527.C558@10.0.0.1> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <200709190143.l8J1hJKA074148@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:15:17 -0000 On Tue, 18 Sep 2007, Garrett Wollman wrote: > Jeff Roberson writes: > >> Is there a good reason for not making ticks 64bit? math involving this >> value is relatively infrequent. Bruce? Any comments? It'd sure let us >> forget all of these counter wrapping problems. > > Making ticks 64 bits on 32-bit architectures means that updates to it > will not be atomic. You're right. There would be a chance that you'd get mismatched upper and lower halves on wrap conditions and would have to detect accordingly. That's probably too much trouble. Thanks, Jeff > > -GAWollman > > -- > Garrett A. Wollman | The real tragedy of human existence is not that we are > wollman@csail.mit.edu| nasty by nature, but that a cruel structural asymmetry > Opinions not those | grants to rare events of meanness such power to shape > of MIT or CSAIL. | our history. - S.J. Gould, Ten Thousand Acts of Kindness > From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 03:08:45 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C10CE16A419; Wed, 19 Sep 2007 03:08:45 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 78F4413C468; Wed, 19 Sep 2007 03:08:45 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 18 Sep 2007 19:34:48 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l8J2e9RN013555; Tue, 18 Sep 2007 19:40:09 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l8J2e9kY013554; Tue, 18 Sep 2007 19:40:09 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200709190240.l8J2e9kY013554@ambrisko.com> In-Reply-To: <46F05F88.5060809@errno.com> To: Sam Leffler Date: Tue, 18 Sep 2007 19:40:09 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Andre Oppermann , Julian Elischer , arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 03:08:45 -0000 Sam Leffler writes: [snip] | ticks is used a lot. I'd rather set hz back to 100 by default. This | approach is a perfect example of ignoring low-end platforms. FWIW, we set hz to 200 on a bunch of machines so that they don't get interrupted to death. Also the number of interrupts are hz * number of cores in which the number of cores is going up quickly. Doug A. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 04:57:21 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3431D16A420; Wed, 19 Sep 2007 04:57:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9F29A13C45D; Wed, 19 Sep 2007 04:57:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l8J4tZao031321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2007 14:55:38 +1000 Date: Wed, 19 Sep 2007 14:55:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Julian Elischer In-Reply-To: <46F0656A.7030802@elischer.org> Message-ID: <20070919133525.E78370@besplex.bde.org> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <20070918153536.D558@10.0.0.1> <46F05F88.5060809@errno.com> <46F0656A.7030802@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 04:57:21 -0000 On Tue, 18 Sep 2007, Julian Elischer wrote: > Sam Leffler wrote: >> Jeff Roberson wrote: >>> On Tue, 18 Sep 2007, Jeff Roberson wrote: >>> >>>> On Tue, 18 Sep 2007, Andre Oppermann wrote: >>>>> ... >>>>> ticks is 2^31 on x86 and at HZ=1000 is wraps within a reasonable >>>>> short uptime. You have to make sure that your code handles that >>>>> correctly or you run into lots of strange effects which are almost >>>>> impossible to reproduce. In TCP we've got bitten by that. >>>> >>>> Thanks Andre, this is a good point. For the td_slptime I don't think >>>> it's of practical concern. However, for swtime I think I will convert it >>>> then to seconds from boot. IIRC, the patch only uses deltas of `ticks', so its wraparound doesn't matter, provided you actually use it often enough. Often enough is at least once every 497 days with HZ = 100, or just every 49.7 days with HZ = 1000. >>> Is there a good reason for not making ticks 64bit? I think this would be only a small pessimization, unless accesses to `ticks' are fully locked or made atomic. The clock interrupt handler can interrupt almost anything, but almost nothing locks out clock interrupts. The lock for the write access to `ticks' in hardclock() is (rather bogusly) callout_lock, and sofclock() uses this lock for read accesses without really trying, but generic code can't be expected to know about this and in fact doesn't know about it -- `ticks' seems to be used mainly in netinet where there is no callout_lock'ing in sight. Without locking: with a 32-bit `ticks', read accesses not using atomic_read() are probably atomic, so the race would just give an out of date value, and this shouldn't matter -- the reader cannot tell the difference between a value that is out of date when it is read or one that becomes out of date 1 instruction after it is read; with a 64-bit `ticks' on 32-bit machines, read accesses would not be atomic and the value would sometimes be garbage. >>> math involving this >>> value is relatively infrequent. Bruce? Any comments? It'd sure let us >>> forget all of these counter wrapping problems. >> >> ticks is used a lot. I'd rather set hz back to 100 by default. This >> approach is a perfect example of ignoring low-end platforms. I agree. However, one variable isn't going to make much difference. fs code is full of unecessary 64-bit calculations but no one notices the real-time pessimization from this, at least on non-low-end platforms (I only notice the code bloat). > but it still needs to work on systems with high hz values. Just changing its type won't fix all such problems, but will cause new ones. E.g., in tcp_timer(): % int tick = ticks; This will truncate `ticks'. Truncation is the right thing to do in most places that only need a small delta, but... % ... % CTR6(KTR_NET, "%p %s inp %p active %x tick %i nextc %i", % tp, __func__, inp, tt->tt_active, tick, tt->tt_nextc); Easy to detect breakage of the printf format. Old printf format errors: %p for types other than void *. % ... % if (tick < tt->tt_nextc) % goto rescan; Comparison of truncated value, OK (since both tick and tt_nextc have type int and int overflow is benign on all supported machines). Types should be u_int to avoid undefined behaviour on int overflow. % ... % if (tp->t_state != TCPS_TIME_WAIT && % (ticks - tp->t_rcvtime) <= tcp_maxidle) % tcp_timer_activate(tp, TT_2MSL, tcp_keepintvl); This is already broken on all supported machines, since t_rcvtime has type u_long which is incompatible with the type of both `ticks' and tcp_maxidle (both int). All the types should be truncated to a common unsigned type to get defined behaviour that is not too hard to understand. I think the current behaviour is benign overflow -- t_rcvtime is set to an earlier value of `ticks', and the difference never grows very large. However, changing `ticks' to 64 bits breaks this on non-64-bit machines, -- `ticks' may grow large, but the copy of it in t_rcvtime is limited to u_long = 32 bits on non-64-bit machines, so after about 2^32 ticks of uptime (ticks - tp->t_rcvtime) will always exceed tcp_maxidle. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 08:58:25 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A94116A46D for ; Wed, 19 Sep 2007 08:58:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 07F9513C46B for ; Wed, 19 Sep 2007 08:58:23 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l8J8jR7d001591; Wed, 19 Sep 2007 18:45:27 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l8J8jREP001590; Wed, 19 Sep 2007 18:45:27 +1000 (EST) (envelope-from peter) Date: Wed, 19 Sep 2007 18:45:27 +1000 From: Peter Jeremy To: Bruce Evans Message-ID: <20070919084527.GA1179@turion.vk2pj.dyndns.org> References: <20070917165657.B558@10.0.0.1> <46EF644E.9050207@elischer.org> <20070918012555.G558@10.0.0.1> <46EFE4BD.4030505@freebsd.org> <20070918142115.C558@10.0.0.1> <20070918153536.D558@10.0.0.1> <46F05F88.5060809@errno.com> <46F0656A.7030802@elischer.org> <20070919133525.E78370@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20070919133525.E78370@besplex.bde.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@freebsd.org Subject: Re: 64bit ticks, was Re: Changing p_swtime and td_slptime to ticks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 08:58:25 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Sep-19 14:55:35 +1000, Bruce Evans wrote: >I agree. However, one variable isn't going to make much difference. fs >code is full of unecessary 64-bit calculations but no one notices the >real-time pessimization from this, at least on non-low-end platforms (I >only notice the code bloat). I suspect the pessimization from the 64-bit arithmetic is masked by the requirement that the FS code talk to (mostly rotating) media. The cost of an extra couple of instructions gets lost in the noise as soon as you look at disk latencies. --=20 Peter Jeremy --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG8OGn/opHv/APuIcRAnsaAKCBMga+Z1YF6FyszCzJEMsq7WxUUgCgn8WF ZMYy8zEUPnljXr43y3PpNRc= =4kon -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 19:16:18 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C10D116A46B for ; Wed, 19 Sep 2007 19:16:18 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.74]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5AB13C4A8 for ; Wed, 19 Sep 2007 19:16:18 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpoutm.mac.com (Xserve/smtpout011/MantshX 4.0) with ESMTP id l8JJ4c5p006243 for ; Wed, 19 Sep 2007 12:04:38 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l8JJ4aNW028045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Sep 2007 12:04:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: arch@freebsd.org From: Marcel Moolenaar Date: Wed, 19 Sep 2007 12:03:20 -0700 X-Mailer: Apple Mail (2.752.3) Cc: Subject: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 19:16:18 -0000 All, With FreeBSD being used in various situations, including the embedded space, there seems to be an increasing need to have fine-grained control over what the kernel prints to the console during boot as well as during normal operation. It is my believe at least that the all or nothing approach that we have now is inadequate. With this email I'd like to start a discussion in an attempt to get some feel for what is possible and/or acceptable as well as get more information about the situations where the current behaviour of FreeBSD had to be changed (or people wished it would change). We currently have standard, verbose and mute. Standard is really already too verbose from a regular user (i.e. non-developer) point of view. Mute is really not adequate, because you may want to print at least the copyright notice or provide a couple of lines of critical information even when you don't wont to see anything else. On top of that, if we shift our thinking towards the theoretical, futuristical and/or luxurious then we may be faced with multiple output devices, such as a small LCD, onto which we want to print some status information. With multiple output devices we may want to channel different kinds of messages to different devices. As a first stab, I'm thinking that if we amend the printf()s with a syslog-type facility and/or level, we may achieve just that. Replacing printf with klog() and change the printf implementation to be in terms of a klog call with an as of yet unspecified level and/or facility would help migrate from one system to another. What do people think of such an ability? Have people implemented something similar as part of their own FreeBSD-based solutions? If we have the ability to suppress certain kinds of output, do we still want save the supressed output somewhere and do we want to be able to have fine-grained control over that too? Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 19:25:44 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63D0716A419 for ; Wed, 19 Sep 2007 19:25:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF8013C4B3 for ; Wed, 19 Sep 2007 19:25:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 74F8917104; Wed, 19 Sep 2007 19:25:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l8JJPhDf003933; Wed, 19 Sep 2007 19:25:43 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 19 Sep 2007 12:03:20 MST." <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> Date: Wed, 19 Sep 2007 19:25:43 +0000 Message-ID: <3932.1190229943@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 19:25:44 -0000 >What do people think of such an ability? You should re-read the "consoled revisited" post I made to arch@ some time ago, there are a couple of details you overlook. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 19:56:25 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7263D16A421 for ; Wed, 19 Sep 2007 19:56:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4BA13C465 for ; Wed, 19 Sep 2007 19:56:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5BD431A4D7C; Wed, 19 Sep 2007 12:31:50 -0700 (PDT) Date: Wed, 19 Sep 2007 12:31:50 -0700 From: Alfred Perlstein To: Marcel Moolenaar Message-ID: <20070919193150.GM79417@elvis.mu.org> References: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 19:56:25 -0000 * Marcel Moolenaar [070919 12:16] wrote: > All, > > With FreeBSD being used in various situations, including the embedded > space, there seems to be an increasing need to have fine-grained > control over what the kernel prints to the console during boot as well > as during normal operation. It is my believe at least that the all or > nothing approach that we have now is inadequate. > > With this email I'd like to start a discussion in an attempt to get > some feel for what is possible and/or acceptable as well as get more > information about the situations where the current behaviour of > FreeBSD had to be changed (or people wished it would change). > > We currently have standard, verbose and mute. Standard is really > already too verbose from a regular user (i.e. non-developer) > point of view. Mute is really not adequate, because you may want > to print at least the copyright notice or provide a couple of > lines of critical information even when you don't wont to see > anything else. > > On top of that, if we shift our thinking towards the theoretical, > futuristical and/or luxurious then we may be faced with multiple > output devices, such as a small LCD, onto which we want to print > some status information. With multiple output devices we may want > to channel different kinds of messages to different devices. > > As a first stab, I'm thinking that if we amend the printf()s with > a syslog-type facility and/or level, we may achieve just that. > Replacing printf with klog() and change the printf implementation > to be in terms of a klog call with an as of yet unspecified level > and/or facility would help migrate from one system to another. > > What do people think of such an ability? > > Have people implemented something similar as part of their own > FreeBSD-based solutions? > > If we have the ability to suppress certain kinds of output, > do we still want save the supressed output somewhere and do > we want to be able to have fine-grained control over that too? Marcel, A while ago I was faced with a similar issue, mostly dealing with debug levels. What I came up with was an IDL for defining debug levels and an API for accessing them via string lookup. In effect one could define a tree, akin to sysctl that provided all these layers. Additionally the API allowed for recursive incrementing and decrementing the nodes in the tree. Effectively a description file like this: all all.kern all.kern.dev all.kern.dev.fxp all.kern.dev.fxp.rx all.kern.dev.fxp.tx all.kern.nfs all.kern.nfs.client all.kern.nfs.client.nfsiod all.kern.nfs.server .. Then inside the program one would simply write: alfred_printf(all_kern_dev_fxp, 1, "Fxp initialized"); then maybe in the rx routine: alfred_printf(all_kern_dev_fxp_rx, 2, "Fxp got packet"); the IDL "compiler" would emit a header with extern declarations for all of these integers and a C file with then instantiated along with a lookup table to map strings to these integers. A small library would then allow for the operations to either increase or decrease a particular debug integer or recursively operate on a subtree. This allowed one to for instance make fxp _very_ verbose for a short time. Since the alfred_printf directly pointed at the integer in question the overhead of not printing was simply a branch. For extremely hot spots I would conditionally compile in the code for logging, but in practice this was hardly needed. You could see this being a system where all.kern.log is set to 1 by default, with everything off, an api for setting log variables via the loader (tunables) would provide for adequate means of setting the debug knobs early on. One last facility that I have implemented, but not within the same system is a count-down for how many log records to emit. for instance, I may want to sample about 1000 records from fxp, therefore I would provide a count down integer for the driver itself that would be set to 1000 and if both the log level is set, AND the integer is greater than zero, then the log message would be emitted as well as the integer decremented. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 21:17:26 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D74816A417 for ; Wed, 19 Sep 2007 21:17:26 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.74]) by mx1.freebsd.org (Postfix) with ESMTP id EB2BF13C45E for ; Wed, 19 Sep 2007 21:17:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpoutm.mac.com (Xserve/smtpout011/MantshX 4.0) with ESMTP id l8JLHPWQ026534; Wed, 19 Sep 2007 14:17:25 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l8JLHNCU026463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Sep 2007 14:17:24 -0700 (PDT) In-Reply-To: <3932.1190229943@critter.freebsd.dk> References: <3932.1190229943@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8697991F-F97B-4D19-8712-91162AFA5A66@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 19 Sep 2007 14:16:12 -0700 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 21:17:26 -0000 On Sep 19, 2007, at 12:25 PM, Poul-Henning Kamp wrote: > >> What do people think of such an ability? > > You should re-read the "consoled revisited" post I made to arch@ > some time ago, there are a couple of details you overlook. Are you referring to: http://lists.freebsd.org/mailman/htdig/freebsd-arch/2006-May/005224.html -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Wed Sep 19 22:57:17 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 783E816A474 for ; Wed, 19 Sep 2007 22:57:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 3777613C461 for ; Wed, 19 Sep 2007 22:57:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 19 Sep 2007 15:51:54 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l8JMvGNu085615; Wed, 19 Sep 2007 15:57:16 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l8JMvGAQ085614; Wed, 19 Sep 2007 15:57:16 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200709192257.l8JMvGAQ085614@ambrisko.com> In-Reply-To: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> To: Marcel Moolenaar Date: Wed, 19 Sep 2007 15:57:16 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 22:57:17 -0000 Marcel Moolenaar writes: | With FreeBSD being used in various situations, including the embedded | space, there seems to be an increasing need to have fine-grained | control over what the kernel prints to the console during boot as well | as during normal operation. It is my believe at least that the all or | nothing approach that we have now is inadequate. | | With this email I'd like to start a discussion in an attempt to get | some feel for what is possible and/or acceptable as well as get more | information about the situations where the current behaviour of | FreeBSD had to be changed (or people wished it would change). | | We currently have standard, verbose and mute. Standard is really | already too verbose from a regular user (i.e. non-developer) | point of view. Mute is really not adequate, because you may want | to print at least the copyright notice or provide a couple of | lines of critical information even when you don't wont to see | anything else. | | On top of that, if we shift our thinking towards the theoretical, | futuristical and/or luxurious then we may be faced with multiple | output devices, such as a small LCD, onto which we want to print | some status information. With multiple output devices we may want | to channel different kinds of messages to different devices. | | As a first stab, I'm thinking that if we amend the printf()s with | a syslog-type facility and/or level, we may achieve just that. | Replacing printf with klog() and change the printf implementation | to be in terms of a klog call with an as of yet unspecified level | and/or facility would help migrate from one system to another. | | What do people think of such an ability? | | Have people implemented something similar as part of their own | FreeBSD-based solutions? | | If we have the ability to suppress certain kinds of output, | do we still want save the supressed output somewhere and do | we want to be able to have fine-grained control over that too? As a person that has done a bunch of appliance work I wouldn't support this. What I/other companies have done is just to mute the console and decide on what and when messages of our own should be displayed. Okay, we do hacks so if the machine panic's it will un-mute the console and dump it to a serial port. Also it will dump a smaller sub-set to ipmi system event logs. Note this does require a bit of code change since the kernel needs to flip the consmute back and forth so I made a function call deal with it. Also serial gizmo's etc. can require a non-standard communication method so doing a "kernel printf" might not work with just ascii text. I've also done this for BIOSs which we need to display codes to an LCD so we can display bad memory errors etc. What generic mechanism you proprose wouldn't meet everyone's needs so then it is easier for them to just implement their needs. It isn't that hard and even with a muted console you get dmesg/console.log output etc. (okay that might be with my patched version). Then you can parse the logs and spit them out. You can even make syslog run the parser. I think we need to keep FreeBSD simple and selecting a serial, vga or muted console is fine. I also have a patch so that you can tell the kernel it is a muted, serial console since that info is lost from the loader -> kernel since it sets console= so if console=nullconsole then the kernel doesn't know if the serial console was muted or not. So I made a new altconsole variable so then we set console=nullconsole altconsole=comconsole so then kernel knows what console is muted. Other variables/schemes could be used but this works for me for now. It would be nice to have both a vga and serial console :-) There used to be "dual" console at the boot blocks level. Doug A. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 20 05:15:56 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C26C816A419 for ; Thu, 20 Sep 2007 05:15:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7698413C45A for ; Thu, 20 Sep 2007 05:15:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7133617104; Thu, 20 Sep 2007 05:15:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l8K5FuCc005709; Thu, 20 Sep 2007 05:15:57 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 19 Sep 2007 14:16:12 MST." <8697991F-F97B-4D19-8712-91162AFA5A66@mac.com> Date: Thu, 20 Sep 2007 05:15:56 +0000 Message-ID: <5708.1190265356@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 05:15:56 -0000 In message <8697991F-F97B-4D19-8712-91162AFA5A66@mac.com>, Marcel Moolenaar wri tes: > >On Sep 19, 2007, at 12:25 PM, Poul-Henning Kamp wrote: > >> >>> What do people think of such an ability? >> >> You should re-read the "consoled revisited" post I made to arch@ >> some time ago, there are a couple of details you overlook. > >Are you referring to: >http://lists.freebsd.org/mailman/htdig/freebsd-arch/2006-May/005224.html Yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 20 21:18:01 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C653316A507 for ; Thu, 20 Sep 2007 21:18:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.71]) by mx1.freebsd.org (Postfix) with ESMTP id E493913C743 for ; Thu, 20 Sep 2007 21:16:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpoutm.mac.com (Xserve/smtpout008/MantshX 4.0) with ESMTP id l8KH1Gci011049; Thu, 20 Sep 2007 10:01:16 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id l8KH1E3W026161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2007 10:01:14 -0700 (PDT) In-Reply-To: <200709192257.l8JMvGAQ085614@ambrisko.com> References: <200709192257.l8JMvGAQ085614@ambrisko.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <04C1A383-2376-47DC-92A6-FA1EBF1B9E83@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 20 Sep 2007 10:00:01 -0700 To: Doug Ambrisko X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:18:02 -0000 On Sep 19, 2007, at 3:57 PM, Doug Ambrisko wrote: > As a person that has done a bunch of appliance work I wouldn't > support this. What I/other companies have done is just to mute > the console and decide on what and when messages of our own should > be displayed. I've read this over a couple of times and it still strikes me as an odd statement. What I posed for discussion is exactly what you've done (or had to do) and yet you don't support it. > What generic mechanism you proprose wouldn't meet everyone's > needs so then it is easier for them to just implement their > needs. I didn't propose anything yet. I merely stated an example. The intend is to find out if a generic method exists that works for everyone, and if not, to what extend we can make it flexible and generic without trying to meet everyone's needs. You advocate that people implement (and re-implement) what they need based on the status quo. I don't see how it is impossible to change the status quo and still have people implement (and re-implement) what they need, provided we don't make things impossible. In other words, if some future infrastructure supports the status quo, no matter how complex we make it otherwise, then your needs are met aren't they? > I think we need to keep FreeBSD simple and selecting a > serial, vga or muted console is fine. No, I don't think it is. For example, we already support using all devices as console with the -D option. With EFI, where multiple consoles can be configured this would be a useful feature so that the OS outputs to the same devices the firmware does. But what about our firewire console or serial over USB? And what about headless setups when there's only a LCD? What I'm trying to say is that a PC-centric point of view as a basis for a design is too limited. You already acknowledge that, because you had to make changes and hack the code to make it fit your needs. So, things aren't fine according to my interpretation. > I also have a patch > so that you can tell the kernel it is a muted, serial console > since that info is lost from the loader -> kernel since > it sets console= so if console=nullconsole then the > kernel doesn't know if the serial console was muted or not. > So I made a new altconsole variable so then we set > console=nullconsole > altconsole=comconsole > so then kernel knows what console is muted. This is very PC oriented. These variables mean nothing on sparc64, powerpc or ia64 for example. There's nothing I can do with what you say here. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Sep 20 21:22:13 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CD9016A54B; Thu, 20 Sep 2007 21:22:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.74]) by mx1.freebsd.org (Postfix) with ESMTP id F351013C632; Thu, 20 Sep 2007 21:22:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpoutm.mac.com (Xserve/smtpout011/MantshX 4.0) with ESMTP id l8KH9f1P015961; Thu, 20 Sep 2007 10:09:41 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l8KH9bPp020929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2007 10:09:38 -0700 (PDT) In-Reply-To: <20070919193150.GM79417@elvis.mu.org> References: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> <20070919193150.GM79417@elvis.mu.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 20 Sep 2007 10:08:25 -0700 To: Alfred Perlstein X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:22:13 -0000 On Sep 19, 2007, at 12:31 PM, Alfred Perlstein wrote: ... > In effect one could define a tree, akin to sysctl that provided > all these layers. ... > Effectively a description file like this: > > all > all.kern > all.kern.dev > all.kern.dev.fxp > all.kern.dev.fxp.rx > all.kern.dev.fxp.tx > .. ... > Then inside the program one would simply write: > > alfred_printf(all_kern_dev_fxp, 1, "Fxp initialized"); > > then maybe in the rx routine: > > alfred_printf(all_kern_dev_fxp_rx, 2, "Fxp got packet"); For some reason this struck a note. While this was done for debug levels and may not directly apply to generic console output and redirection, it did put a seed in my head relating to device_printf(). Nothing concrete and it may not be anything, but still :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Sep 20 21:30:58 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F56B16A417 for ; Thu, 20 Sep 2007 21:30:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4515513C461 for ; Thu, 20 Sep 2007 21:30:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 10D301A4D9F; Thu, 20 Sep 2007 14:30:58 -0700 (PDT) Date: Thu, 20 Sep 2007 14:30:58 -0700 From: Alfred Perlstein To: Marcel Moolenaar Message-ID: <20070920213057.GV79417@elvis.mu.org> References: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> <20070919193150.GM79417@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:30:58 -0000 * Marcel Moolenaar [070920 14:22] wrote: > On Sep 19, 2007, at 12:31 PM, Alfred Perlstein wrote: > > ... > >In effect one could define a tree, akin to sysctl that provided > >all these layers. > ... > >Effectively a description file like this: > > > > all > > all.kern > > all.kern.dev > > all.kern.dev.fxp > > all.kern.dev.fxp.rx > > all.kern.dev.fxp.tx > > .. > ... > >Then inside the program one would simply write: > > > >alfred_printf(all_kern_dev_fxp, 1, "Fxp initialized"); > > > >then maybe in the rx routine: > > > >alfred_printf(all_kern_dev_fxp_rx, 2, "Fxp got packet"); > > > For some reason this struck a note. While this was done > for debug levels and may not directly apply to generic > console output and redirection, it did put a seed in my > head relating to device_printf(). Nothing concrete and > it may not be anything, but still :-) so you like it? I do! -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sat Sep 22 18:42:36 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2109C16A418 for ; Sat, 22 Sep 2007 18:42:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.76]) by mx1.freebsd.org (Postfix) with ESMTP id 139A313C46E for ; Sat, 22 Sep 2007 18:42:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id l8MIgZL1002164; Sat, 22 Sep 2007 11:42:35 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l8MIgXCP029419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Sep 2007 11:42:34 -0700 (PDT) In-Reply-To: <5708.1190265356@critter.freebsd.dk> References: <5708.1190265356@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 22 Sep 2007 11:41:15 -0700 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 18:42:36 -0000 On Sep 19, 2007, at 10:15 PM, Poul-Henning Kamp wrote: > In message <8697991F-F97B-4D19-8712-91162AFA5A66@mac.com>, Marcel > Moolenaar wri > tes: >> >> On Sep 19, 2007, at 12:25 PM, Poul-Henning Kamp wrote: >> >>> >>>> What do people think of such an ability? >>> >>> You should re-read the "consoled revisited" post I made to arch@ >>> some time ago, there are a couple of details you overlook. >> >> Are you referring to: >> http://lists.freebsd.org/mailman/htdig/freebsd-arch/2006-May/ >> 005224.html > > Yes. Ok. Let's throw it in. Try this on for size: Let's define "the low-level console" as nothing more than a switchboard. It conceptually has sources and sinks and by means of an as of yet undefined method allows connecting sources to 0 or more sinks. Sources and sinks are as of yet undefined KOBJ interfaces (but let's assume for now that they match the CONS_DRIVER/CONSOLE_DRIVER interface). Let's define "the console" as the console device (i.e. /dev/console), which is nothing more than a conduit between the file/tty layer and the low-level console (aka switchboard) as connects as a source. Let's assume that opening the console will create a new instance and thus a new independent source into the switchboard. At least that seems to me to be a good idea now :-) Now, back to my original posting. We define printf(9) a source into the switchboard. But, I proposed that we want more fine-grained control over what gets "printed" where. In other words, we want printf(9) to behave as if it was connected as multiple sources, each configured with its own set of sinks. Another way of looking at it is by borrowing from USB: Each sources/sink is device and each device can have multiple endpoints. We create pipes between endpoints and the low-level console operates on pipes. Unlike USB pipes in this context can have multiple endpoint sinks. Without going deeper and into more detail: would such a concept be a good basis to work things out? Some examples to make it less abstract: o cninit() initializes the low-level console (i.e. the switchboard. It will register the CONS_DRIVER set as sinks and will create some initial (set of) sources. Depict this as working the same as we have now, just with some conceptual differences. It is possible that no sinks exist initially, which probably means that everything coming in from sources gets discarded. As a default we can connect all sources to all sinks? o The msgbuf will eventually be created and in the new world order, will become an independent sink. This could be the only sink, which means that everything gets "printed" to the msgbuf. By default we connect all sources to the msgbuf? o /sbin/init will eventually open /dev/console, which becomes a new source and by some undefined means will be connected to sinks. Maybe all sinks? o If, say, we have a serial console (in the current scheme of things), we typically also spawn getty(8) on the corresponding device special file. Opening the device special should in some undefined way affect the low-level console, because the serial port may also have been registered as a sink by way of being a CONS_DRIVER. Removing the corresponding CONS_DRIVER from the low-level console seems like the right thing to do. Thoughts? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Sat Sep 22 19:15:49 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2034D16A41A for ; Sat, 22 Sep 2007 19:15:49 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DF9BA13C48D for ; Sat, 22 Sep 2007 19:15:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6958017104; Sat, 22 Sep 2007 19:15:47 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l8MJFpSa022167; Sat, 22 Sep 2007 19:15:51 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 22 Sep 2007 11:41:15 MST." Date: Sat, 22 Sep 2007 19:15:51 +0000 Message-ID: <22166.1190488551@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 19:15:49 -0000 In message , Marcel Moolenaar wri tes: >>> Are you referring to: >>> http://lists.freebsd.org/mailman/htdig/freebsd-arch/2006-May/ >>> 005224.html > >Let's define "the low-level console" as nothing more than a >switchboard. The reason I didn't go that route, is that the "streams" have vastly different sematics, some are even bidirectional. At the very least you need to think carefully about all of the four distinct phases: Before the kernel runs Kernel until /sbin/init /sbin/init and single user mode Multiuser mode. Lumping them all together is what we have today, which we both recognize as not the way to go. I fully agree that printf(9) is an unholy tangle of all sorts of messages and that it should be possible to sort them, but that is only a small part of the console puzzle, and fixing that should not make the current tangle any worse. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Sep 22 19:47:33 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD32B16A417 for ; Sat, 22 Sep 2007 19:47:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.75]) by mx1.freebsd.org (Postfix) with ESMTP id D5C5813C447 for ; Sat, 22 Sep 2007 19:47:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpoutm.mac.com (Xserve/smtpout012/MantshX 4.0) with ESMTP id l8MJlXPJ002081; Sat, 22 Sep 2007 12:47:33 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l8MJlV5k020947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Sep 2007 12:47:32 -0700 (PDT) In-Reply-To: <22166.1190488551@critter.freebsd.dk> References: <22166.1190488551@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 22 Sep 2007 12:46:13 -0700 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 19:47:33 -0000 On Sep 22, 2007, at 12:15 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >>>> Are you referring to: >>>> http://lists.freebsd.org/mailman/htdig/freebsd-arch/2006-May/ >>>> 005224.html >> >> Let's define "the low-level console" as nothing more than a >> switchboard. > > The reason I didn't go that route, is that the "streams" > have vastly different sematics, some are even bidirectional. The source vs. sink nomenclature can be confusing, but assuming that all pipes/streams are bi-directional is probably a good way to avoid mistakes. The kernel will ask for input if you boot with -a, so even before we run /sbin/init we need a bi-directional pipe. Of course, display hardware does not allow for input in the same way that a keyboard does not allow for output, but I'm not too concerned about that. It'll fall into place all by itself. For real hardware (i.e. displays, keyboards. etc), there's syscons (or its replacement) that will provide the abstraction and create a single sink into the switchboard. For the msgbuf, we simply have no input coming from that sink ever... I don't see how semantics differ though. Can you give an example? > At the very least you need to think carefully about all of > the four distinct phases: > > Before the kernel runs > Kernel until /sbin/init > /sbin/init and single user mode > Multiuser mode. > > Lumping them all together is what we have today, which we > both recognize as not the way to go. Agreed. We should not lump them together. However, they are interrelated, so we cannot treat them independently either. The switchboard approach was a way to 1) untangle the low- level console from /dev/console and 2) allow everything to be interconnected in some form of shape without backchannels and/or hooks. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Sat Sep 22 20:03:48 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF4F516A417 for ; Sat, 22 Sep 2007 20:03:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF1413C458 for ; Sat, 22 Sep 2007 20:03:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1C66317104; Sat, 22 Sep 2007 20:03:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l8MK3pJF022305; Sat, 22 Sep 2007 20:03:51 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 22 Sep 2007 12:46:13 MST." Date: Sat, 22 Sep 2007 20:03:51 +0000 Message-ID: <22304.1190491431@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 20:03:48 -0000 In message , Marcel Moolenaar wri tes: >Agreed. We should not lump them together. However, they are >interrelated, so we cannot treat them independently either. >The switchboard approach was a way to 1) untangle the low- >level console from /dev/console and 2) allow everything to >be interconnected in some form of shape without backchannels >and/or hooks. I'm deeply sceptical, but if you think you know how to do it, in a way that still works in a panic context, by all means try it out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.