From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from YT3PR01CU008.outbound.protection.outlook.com (mail-canadacentralazon11020129.outbound.protection.outlook.com [52.101.189.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 741F528C866 for ; Mon, 17 Nov 2025 19:05:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.189.129 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763406326; cv=fail; b=fiqnaHmM+DwbqSW1S9oSKVohQmw9fATjiccJO2UhNqnYfQ8Q8DOMfbr9U1w+yWQARnw+Kzc91bYAsMEOBIhGGngd3Wx3XAGNgjvhDmJJfuGqH3L78d02kuAzVJ5v+u4n7ChwowV5W67EgWLs/zKPlR/ZuGeXvhfh4JT+zlWTWMQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763406326; c=relaxed/simple; bh=04/ZyojJjf3LT9zso9jD2S5RaaI+k6QAnUcRsIKmGyc=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=b+f2KepCLrpJOEAw5ukCOdOc3RPTFGeQsvOQy0sV7Jqjnvbrm9d5jhLb2Wz4TqLR2AeIcWSTVszjmxo2ojgv/hJD9XuVp0b0BXrScvixyyQoZ6IrJWJQEtPmu/1zvDsaPiQn25OwQn45wXp1f8NvwZMwUTTwFzwwYoywgXO//1s= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=Kzotph2L; arc=fail smtp.client-ip=52.101.189.129 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="Kzotph2L" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=U1+1k2vqoWQHdVIOkfbREx8L+DOK61Z3zerCXCfJnYbK1emSjOrqQ+N+xoKk6IyszKss/j0pvsAqEYNqcbu4osyQxqXRgVLNm/ap30cJDhVP2SbqbYO2K0g4aIwVeJEFAJpRn1l+WHJVQlF8MEdgJsnM64hC3Jx3tlYnzUlWZ6mGHgzGjBTJmPBBJJelO3R3EhnusK969aJHRdSAB2EvF49umlp6gyEW+miDii0QM/3WsY/ieRnIpA0quDEq0evL+oT1pQlxTO0ACT4EEQzF+DhHEan+BHG1cDwuPL4vtogMg73JjBawtKG/j5zakXOn5p1NizBQLod8rp481XbNTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2eebDJBdmpXJ43dSphHhUkONF3rGO2es8lzwmJZRRDE=; b=llkBvSj8oqyFc3cwx2had08d5qUJCgSl0hHeG46/21vh1LuNdmfFQYfGQgiLsh45wSULkhTuKqgJQxbGXxAg5oRWe9LzopVnsxL1j+utZCDY228vfy8p4mKn8eeEd5K4plC59cLgwZoGCEz7aW1GOBjQON1s2eDoGCGdAIJVJMHlmCoN2CzWyMWdCYfU18gJpMA7nXA6itZB8hBOLDoFZC1eYOL6C7VF2HZLUaQjeuTeMo73CYJa0j5u0saEGaSgh/ssoBZnTnO83HeVPlbUw0GjMsvtTloUOH/2yRKF12NckHulwGYR/9eNBA+FEF7/fM5g9H+lfnNfai4WvGLmug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2eebDJBdmpXJ43dSphHhUkONF3rGO2es8lzwmJZRRDE=; b=Kzotph2LDVmdfyNM6nIlfipvbY665v48Y62SrL3M4yKVDm8Sc+ffSb2owsxXi8gB+gZHulhHvTEvFhW6hp6tp+SJIzdJ1mByCcfS5ZizxzvLcf/uxTBdXNobNVfZgZiwvc84ya8yoRmTu0mImEV/tR4SsK2NjZ/699/0ifCWo+s+PUeNkzBoRZriNt3M0fQaZsW/nBQL+gJfTVJZ+z+yKm6KLHNbLRMTmEERKWJ0lfRZH3ObIQrxNbOL7HKiEoTIKQBiLK3aP1sdEozlygnA/yzi6wrWpbLrh02Kc1H1AOTPyU1Q9sl32i4bzzvg6d+jskzsHg6VD0yko5gbiEQ3yg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) by YT3PR01MB8884.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:7d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9320.22; Mon, 17 Nov 2025 19:05:19 +0000 Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::50f1:2e3f:a5dd:5b4]) by YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::50f1:2e3f:a5dd:5b4%2]) with mapi id 15.20.9320.021; Mon, 17 Nov 2025 19:05:18 +0000 Message-ID: <6fbc0d79-f2b3-447d-a173-22bb11a30561@efficios.com> Date: Mon, 17 Nov 2025 14:05:16 -0500 User-Agent: Mozilla Thunderbird Subject: Re: [patch V4 15/20] sched/mmcid: Introduce per task/CPU ownership infrastructure To: Thomas Gleixner , LKML Cc: Peter Zijlstra , Gabriele Monaco , Michael Jeanson , Jens Axboe , "Paul E. McKenney" , "Gautham R. Shenoy" , Florian Weimer , Tim Chen , Yury Norov , Shrikanth Hegde References: <20251104075053.700034556@linutronix.de> <20251104075427.635449783@linutronix.de> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: <20251104075427.635449783@linutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: YQ1P288CA0022.CANP288.PROD.OUTLOOK.COM (2603:10b6:c01:9e::11) To YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YT2PR01MB9175:EE_|YT3PR01MB8884:EE_ X-MS-Office365-Filtering-Correlation-Id: dcd5d98e-3818-4575-5dc8-08de260c3f6f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RUUvTlovY0N6Zml2YkMrNDh1TitYanRHS2dKQlVob2VHZldKUXZsYkhieENl?= =?utf-8?B?T1hPZjVZM09Mb1RHbDFUOWwrdE9CdG9DZ3JaeFJTOURIUlN2eDY5NVl0RTdW?= =?utf-8?B?dldJRUFnYU9VZVhhZkw0UFpmTGVsemFjSGo5b3hZcDZKYldnRXE5eUFWdEdi?= =?utf-8?B?Q1AxZnpKbmVEUUo2ZTl0QkRFZ09VVUFha1pwUkdOenl4OEhtT3htSi9QdG02?= =?utf-8?B?SHdPYlZDdjN2OHNqTkdVa3lKcGthRVNPNlo2UHlXQkF5RWpJenpJN0JjbjdI?= =?utf-8?B?S09hdThKQ1ZFQkJTazh1dWxGcHpYaXRWRFlibzBCbkRJOVhyaGpEWEczamNE?= =?utf-8?B?ekNKTkJiV0xwOTBnZHRKaEw2dGRMYjdGVDh0MnVONlZYaVpmOG4yVGliNzc1?= =?utf-8?B?cTRNVyszMlNaOEFpZ3FkdVB1R1Q3dDJsR0VaZ1RoR2xRWm96Q3NNUWhPRjZU?= =?utf-8?B?eGJ4bFJKd21wZTFJK0JvTGJVN3M5Q2RYVHhHdWlyZllUUHA4SmlocXQrQSsr?= =?utf-8?B?ejdrcjRscDZDa2IzcVlyZmszQ3NhMGVxb1NsK2phdW9rOVlMUlBWWGhid1FM?= =?utf-8?B?Zjc2TDJFOEdrdXFGcU01dW5ablZhZVNybFU3U3p1R1E3b2U3cTVRV053R2VD?= =?utf-8?B?Q3hwdC9jVjFOWkV1WUxPMXc4aUk0Mys3all4UGszVStMa0lCUWJKMjFzZTFL?= =?utf-8?B?SnNJZ2lpNXE5TmtGUytOQytxOUFJcCt3cFdoWStKYjhvWm5kNW4wVndUNi9Y?= =?utf-8?B?NUVUUGhKdFMrOWtXOS9WUGxnNjhPOWpRN2w3U2Q2VktUNXdOaXUybnlPMDJl?= =?utf-8?B?TFJTMmxXU0dEQ0pMRVdjZlQ2N2dXN2tnODBScHNRNWlkYVM4VEE0ekRuQlN1?= =?utf-8?B?bFpTZmw3SnVyVEFrcjFHaEpoUTY2bk50RE1CTUNQdjRBY1RkUzNGRk51Y04x?= =?utf-8?B?ZE8zWFR6M1crY1kyamtZRUNEZ0lxb1lFNnlMU3YrMkZTc2lST2llaG1QNFN5?= =?utf-8?B?K2FqejVhbGlkNHMxSWlDRjBUSDRrN0NlL3BVWmNNTlMvT0VhYS9ZeWZMeHdL?= =?utf-8?B?NmRsZlpralF0U3VUNmVZZnQ2NmtMTVVyNDdqOUJvb2UzUi92OUN1S0hJUVFG?= =?utf-8?B?VU5JWldIUFFIeGFncExYd1dVeU5naFpKNG1GZVF6VEg4Y1ExY1V2VUUwNmgw?= =?utf-8?B?b3JqM1M2Z3JVWWJQMmJ1dzBlWEowNnFTVUo0VnBFMWNDaVNhQkdLZUNUaGRy?= =?utf-8?B?a0JyRFZuVml1bXdZYS94Lzg5b3VUM0svNEZhL1NLN3lxcFhQQjRndzJpS3pC?= =?utf-8?B?eGJXaUpTWDIwbGZHZnhRdDF0eDdhZXY1ZTdzS1p4RVhWSWVCV1l3SnNobHRR?= =?utf-8?B?MGdzZzZzSTBUUlBLU0s5L21KUmJtQmdRVTJzRTVVaVFOaWtObVZvQSsvd0Nn?= =?utf-8?B?MFhLalF2OVJPeFgxTU14ZEE0WG9YS0c4ZnUxYm13SER0Vnp5OGthVWlwb0Zy?= =?utf-8?B?Y0dwcEdyUzl0Ym9JMkV1aXk3T0VoZzNsanpuaWZiYnE3dGJtUUdVd05OWFZI?= =?utf-8?B?WVJIMXFOcS9VcE5USm5LQTVHT2R2WDZLY280aXBPckRFQ0kycDNHRzJJSHpV?= =?utf-8?B?YytuenhZUlppd2hISkFvUFBRU0U4Z1Fqanc2cmd0NEdqaFVtbXdLM3ZoTENE?= =?utf-8?B?VjlVSXF4MW9PT2FzRmNCWDJBbkVRNE1Gbi9mSUdjVU1GU1RDL2JUbU9oTmVR?= =?utf-8?B?MUpCRnl2ZitkM293MnZNTEw4MGV5SlBuSk93UU0vdzE3ZWRjR3k3bE5LN3VW?= =?utf-8?B?b0p4Rm5FazFjNGg2N0xJSFQyVit1QlYvZmJEWHJ2TG1oZHU1RVEybjd5ckRL?= =?utf-8?B?NWk4cFQ3ejljSEQ0SlhlYk1ySzdzR1NjR3A3RDRkUGJSV0E9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bDMyUk01MUpyVmtQZHhCT21wbzA0YVpMMS9zN0dBRThaVm4xT0lGclljOHQz?= =?utf-8?B?L3ZLS25qbCtyOW5TSVpIS2o3ZkVDVnY2Mzh1Mk1ybEVBNnZFU3cwLzJEdlN0?= =?utf-8?B?a1B4TCtZUnVFR3IvZ1VnUXdwYXA3MEhJK0kvbEtWZDdSK2FtQXVGSVBsMGNN?= =?utf-8?B?Vk40QWJBbHRqMzVHNHNZUmNlZ1F2ZHl6MnIrcVg2cGN2RmxyOFJoRVBnWFNI?= =?utf-8?B?emM5R3VTNHMwZ0ZRbUMyTmVFUWY3eG9ZOGJUODBPdzhhaVN1dFVPWjFjdWx0?= =?utf-8?B?Mmc4M3I5TmhKd1dFTXlQL3VvUXgyN1I3YUIvZS9DNDJmTm42RGtUMnNYdjBS?= =?utf-8?B?RHRqM1g3OFVlVkxiVWo5VWNXejlhVTUyMCtiV1pqbklNZ25WWmpEOWhIUDJO?= =?utf-8?B?bVJXV3pIeE1MRHZlbVVPZXBjQUFudStnaUEvZDVmdDQvY3l3djRMOUw3T1Fs?= =?utf-8?B?b1lWcHVudGxPeHV1SXlSN0ZYdDdTd1dFcHIvMnd6ajEyM1h2ckRjbGFOOGJa?= =?utf-8?B?NGc0KzUxTE5XTDQwczU4MytFajZadEF4Y3R1NTBtVUlHWDJYa1NabkxjMGly?= =?utf-8?B?RUVmNWFoMzhTbkVrQzREcVcwSmpibzR5czU2eVBhYkRoRkpuYmticzZtQ2RR?= =?utf-8?B?cjBOQitOYUorNlhNaC9lMkdmL0JWd1pRL2k3MmIyOVkxM3dWUkNiWXdkajdS?= =?utf-8?B?cmdGWGNtS0VycHBMQ1FPbU8zQzlTTFgxV1VJWjJkdEV4ZEV5eWRZYWpXd0Rj?= =?utf-8?B?MTMxb09obXMvemFScE5QcUlXTTJLQVBGNmRoVGtDSk93RVhvSE9lMytHMTFE?= =?utf-8?B?TVg2TGkwUmRQQWlYS3FFa0dPaG1PZVFIWElBZnllQ1pKVWhIMVpyM0Y5OGo3?= =?utf-8?B?bVdwelk3dkNkaWVmU0xhaFlZUnZ6ZEZLZGcvaUhKL1E3YnRTYnRoV2RTbGlR?= =?utf-8?B?bXdaWmJxR1Z4V1RzWGhVdW1HYy9WQ2NWSFlONjZuWW9WYU9wbllQM3VVdnBE?= =?utf-8?B?Zm9CaFV0K3NsemRJaEJZTjg3NHdFakQxemlGS2kzaGdYQnJmZGRMNXB0ekh3?= =?utf-8?B?Ti9ZbWF3QzF5TUV2blNlVHo3Umt5Sjh4Q0s4Q0gvRHRxSjhqQ3phZyt1b2I5?= =?utf-8?B?NzJjWmNwZThPS0lQeGViSnF0MzA0SzljeHRwMUxROXpYbVQ2Y2lkTWdxdGJz?= =?utf-8?B?V1pJdzdZU3lQck9YaHptbFEvTnJBZHpxYVJHalV6RzVtT0I4RncwOGVTRU1L?= =?utf-8?B?NUVmRlFUaEZFeDJiZUplaGMzRE91N0J0R0xnbnRLcEdVVmhaUGJRQWd3MnpH?= =?utf-8?B?ZHFYcjFiTk93N0pvSzVHbXlpSnBwMVpyRHhMK3BjMWd3Q28zM2liZitUb3Jl?= =?utf-8?B?RThBMTJlNmM0a2Y1Mis0dFZLWUkvNng3T1ZtMzlGZG44NDVPakF3T1RXYU42?= =?utf-8?B?MUtYZzdtcFhEMk5yY2s3ZnN6TmJQNUZucUJCR0NRZXhObk10bVVhekpnYUNu?= =?utf-8?B?cElIVGRKNGhXSjFvcGlNeVljQ0kyRTNOR3ptbHNub2hXbXN1Q01UdWxSNDVJ?= =?utf-8?B?Q1RiaTVEVjlMbXRPUnYzallGN2w1eWJFeHJGWGNyNVJUb3B3VVJaazEwV2Zk?= =?utf-8?B?dGpKbnFMcWlsenhlNnhxUFhyTHFlMnlvQnZPRk1wZ1ZZc2RuendTOXBHR2Vu?= =?utf-8?B?b25MeW1PVUNGaGNtb1VGN1lJN2lEVGNYdVhoU2hrNmwzTUJnYVRCNTF1eStK?= =?utf-8?B?Y3FQdFdjeWpzSVJ2aTZsR0pjbFBVem5sMU1EOHo0bklsWFBhK3IyTG5Ed2tP?= =?utf-8?B?VXRidFRZMExIaXpuMzA1Z2xuTXpxQS93MDkyYTVkK2liUGdCanVBL2UzT1ls?= =?utf-8?B?UXlMVWZHMzdNNWtDL2xyNVZGRjFtdHlFR1kvd09Ga2x0THhKTTFoOG5hNDBE?= =?utf-8?B?elpGOE9ZQXVnN0ZqcmhFcW9xRnJmUjdYSEtaTElIb1haVkU5aThKQkRWQzU0?= =?utf-8?B?OEYyV2JZWlYwc2JnU0xLRXpaenZBVHdHc1ZyYlpQdTJzVEs2a3gxME9FeEFO?= =?utf-8?B?VWxFditCbGdUUm8rRHdEbk0zY1drUkRqS3Zxd2xrZWR1YUEwSHBKa1h2UUs2?= =?utf-8?B?WkFTd1hHY21BSnpoYlJCSkxERFFUaHE0dHVyNjRkNDZkSmYwK0dyOVBIV3VE?= =?utf-8?Q?5lmyTLLt+zE4rfL6uEGlnPk=3D?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: dcd5d98e-3818-4575-5dc8-08de260c3f6f X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2025 19:05:18.0266 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: gu72W2rJ/gDxpGlRpTyPtIyO/EUIHjFqRC6w/L9FLtsQl7R78+SWfS4rmAQLddVuR9nXCwCVK+2m6yv0n8yZ13/OYZ68/atWTq2pYWtExQo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB8884 On 2025-11-16 15:49, Thomas Gleixner wrote: [...] I'm OK with the proposed change, but I'd like to clarify two points in this commit message in case I'm misunderstanding something. > > The current upstream implementation tries to keep the CID with the task > even in overcommit situations, which complicates task migration. [...] For the sake of this discussion, I will assume that your explanation here is about the upstream implementation before the "sched/mmcid: Revert the complex CID management". I don't agree with your statement above. In the upstream implementation, we have the two following cases in overcommit scenario: __sched_mm_cid_migrate_from_fetch_cid(): /* * If the migrated task has no last cid, or if the current * task on src rq uses the cid, it means the source cid does not need * to be moved to the destination cpu. */ [...] /* * If we observe an active task using the mm on this rq, it means we * are not the last task to be migrated from this cpu for this mm, so * there is no need to move src_cid to the destination cpu. */ The above prevents mm_cid movement for a source CPU which is currently running tasks that use the same mm. sched_mm_cid_migrate_to(): /* * Move the src cid if the dst cid is unset. This keeps id * allocation closest to 0 in cases where few threads migrate around * many CPUs. * * If destination cid or recent cid is already set, we may have * to just clear the src cid to ensure compactness in frequent * migrations scenarios. * * It is not useful to clear the src cid when the number of threads is * greater or equal to the number of allowed CPUs, because user-space * can expect that the number of allowed cids can reach the number of * allowed CPUs. */ [...] if (dst_cid_is_set && atomic_read(&mm->mm_users) >= READ_ONCE(mm->nr_cpus_allowed)) return; The above is really what makes sure that we favor keeping the mm_cid currently allocated on the destination CPU rather than bring over the mm_cid from the source CPU. > This can be done differently by implementing a strict CID ownership > mechanism. Either the CIDs are owned by the tasks or by the CPUs. The > latter provides less locality when tasks are heavily migrating, but there > is no justification to optimize for overcommit scenarios and thereby > penalizing everyone else. AFAIU, the new 2 modes scheme (task vs cpu) makes similar tradeoffs as the upstream implementation, which is to *not* move the mm_cid around in overcommit scenarios, leaving them on their source CPUs. The only two cases where the upstream implementation can be more aggressively moving mm_cid around (when nr_tasks >= nr_allowed_cpus) is when the load balancer does a poor job at load balancing: * When migrating the last task for an mm out of a given CPU. * When the destination CPU does not currently run any tasks for that mm. And I don't think it makes sense to optimize mm_cid compactness for oddly balanced workloads, so I think your new approach makes sense. If you agree with my analysis, we can simply reword the commit message to not imply that there is any expected gain in moving mm_cid with migration in overcommit scenarios, both with the upstream and new implementations. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com