From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id EC4887EE4B for ; Mon, 30 Sep 2013 18:56:54 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel@kerneis.info) identity=pra; client-ip=176.31.113.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel@kerneis.info"; x-sender="gabriel@kerneis.info"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel@kerneis.info designates 176.31.113.173 as permitted sender) identity=mailfrom; client-ip=176.31.113.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel@kerneis.info"; x-sender="gabriel@kerneis.info"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@wanbli.kerneis.info designates 176.31.113.173 as permitted sender) identity=helo; client-ip=176.31.113.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel@kerneis.info"; x-sender="postmaster@wanbli.kerneis.info"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAL2sSVKwH3Gt/2dsb2JhbAA/GoMHOMFPgS4WdIIlAQEFOgYBATcBDwsYCSUPBUmIGQQINqoUhFABBY5KBo9RB4MfgQOOa4kWgTCEd4tTgyU X-IPAS-Result: Ah8FAL2sSVKwH3Gt/2dsb2JhbAA/GoMHOMFPgS4WdIIlAQEFOgYBATcBDwsYCSUPBUmIGQQINqoUhFABBY5KBo9RB4MfgQOOa4kWgTCEd4tTgyU X-IronPort-AV: E=Sophos;i="4.90,1009,1371074400"; d="scan'208";a="28591723" Received: from wanbli.kerneis.info ([176.31.113.173]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 30 Sep 2013 18:56:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kerneis.info; s=wanbli-rsa1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=aUvpvw9gZe70GORL54AVwp3UYVFAKq+StDpo8jGjDbM=; b=Ax0kL8JR50R6DYPf7jz4C+kqv1oQgB4s83cTlmm4p1VGCO1exBWHlSdOm8wH0EbS/zuI+auiDYWksYx9098yCAtVyuXX7abcbS00yp3XGqAEVAyLubTeEVOpgSqbp4lGFioGxNyvp44BCDWkHDbpvhBp/TDZu5O1y4hjZE3fuFM=; Received: from wowasieco.sm.cl.cam.ac.uk ([128.232.60.22] helo=localhost) by wanbli.kerneis.info with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VQgmC-00005o-AF; Mon, 30 Sep 2013 16:56:52 +0000 Date: Mon, 30 Sep 2013 17:56:51 +0100 From: Gabriel Kerneis To: Tom Ridge Cc: Xavier Leroy , caml-list Message-ID: <20130930165651.GA4207@kerneis.info> References: <524941CC.1080906@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 128.232.60.22 X-SA-Exim-Mail-From: gabriel@kerneis.info X-SA-Exim-Scanned: No (on wanbli.kerneis.info); SAEximRunCond expanded to false Subject: Re: [Caml-list] Thread behaviour On Mon, Sep 30, 2013 at 04:12:23PM +0100, Tom Ridge wrote: > > It all depends on the whim of the OS scheduler. OCaml has no control > > over it. And you shoudn't expect any kind of fairness from the OS > > scheduler, esp. Linux's, which gladly jettisons any pretense of > > fairness in the hope of getting better throughput. > > Ah! You are saying that the problem (maybe) lies with the Linux scheduler. > This had never occurred to me. Probably because I assumed the Linux > phrase "completely fair scheduler" meant something (although > admittedly, I never tried to find out what). A bit of off-topic Linux history for those interested: The behaviour of sched_yield() changed in Linux 2.6.23 (with the introduction of the CFS), to adopt a semantics where it does not yield, but only reduces the priority of the calling thread. This change has been debated a lot, in particular because it broke many Java applications. As a work-around, a kernel variable (sched_compat_yield) was introduced to optionnally recover the original behaviour; the rationale for the change was that sched_yield is arguably ill-specified and programs should not rely on it but use (non-portable and tricky) futexes, or (portable) mutexes instead. The variable sched_compat_yield has been remove in Linux 2.6.39, with no clear rationale, during one of the many refactoring of the CFS. As a matter of fact, this change also broke OCaml scheduling. Nowadays, sched_yield() is disabled in the ocaml runtime on Linux. Have a look at http://caml.inria.fr/mantis/view.php?id=2663 for more details on the caml-side of the story (in French). -- Gabriel