From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA14801; Mon, 5 Jul 2004 18:34:23 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA14940 for ; Mon, 5 Jul 2004 18:34:22 +0200 (MET DST) Received: from yquem.inria.fr (yquem.inria.fr [128.93.8.37]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i65GYLEV006112; Mon, 5 Jul 2004 18:34:21 +0200 Received: by yquem.inria.fr (Postfix, from userid 18180) id 7EEF5BBD8; Mon, 5 Jul 2004 18:34:21 +0200 (CEST) Date: Mon, 5 Jul 2004 18:34:21 +0200 From: Xavier Leroy To: Christophe Raffalli Cc: caml-list Subject: Re: [Caml-list] Thread and kernel 2.6 pb still there in CVS Message-ID: <20040705163421.GA12344@yquem.inria.fr> References: <20040624194603.2A91010EF06@clark.cs.brown.edu> <1088158825.1941.113.camel@pelican.wigram> <20040625110748.GB2707@bourg.inria.fr> <1088166608.1941.120.camel@pelican.wigram> <40DC38D3.4010009@univ-savoie.fr> <20040628150805.GC7353@yquem.inria.fr> <40E0D34C.2040808@univ-savoie.fr> <7AFB5F64-C944-11D8-975C-00039310CAE8@inria.fr> <40E11621.3050709@univ-savoie.fr> <40E97058.5060503@univ-savoie.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E97058.5060503@univ-savoie.fr> User-Agent: Mutt/1.3.28i X-Miltered: at nez-perce with ID 40E9830D.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sched:01 refining:99 assess:01 posts:01 sched:01 threads:01 kernel:01 kernel:01 caml:01 caml:01 thread:02 thread:02 bunch:03 somewhere:04 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Just a last question: > Now I saw that for "non broken" sched_yield, the call is still present. > Are you sure that releasing the mutex is not enough to tell the > scheduler it may be a good time to give some cpu to another caml thread > blocked on the same mutex ? In general, when there's code in the Caml implementation, it's for a good reason. > But I am sure you tested that too and this is why the call is still > there when possible ;-) Yes, I tested. Spent more than one day setting up and refining a test harness, then running it on a variety of Linux and non-Linux systems. Had to install a Fedora Core 2 somewhere to assess the damage done in kernel 2.6. In the meantime, read a bunch of condescending mailing list posts along the lines of "if you're using sched_yield(), you must be doing busy-waiting and that's wrong". (Guess what? I'm not doing busy waiting!) The conclusions are clear: sched_yield() does improve fairness and has no significant costs in the situation corresponding to Caml threads (contention on a master lock); and the Linux 2.6 developers managed to make sched_yield() useless for this purpose. If the above sounds mildly irritated, that's because I am. - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners