From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31990C6FD1D for ; Thu, 23 Mar 2023 11:00:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230165AbjCWLAf (ORCPT ); Thu, 23 Mar 2023 07:00:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229616AbjCWLAb (ORCPT ); Thu, 23 Mar 2023 07:00:31 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2EB8B2659F for ; Thu, 23 Mar 2023 03:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679569178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MAscxfxWjnWJvYP+PGVC3a50JuQ7qCpSYPPBetUb0UU=; b=gLQmc0rk/8KJ8RIwOehhtFjn0axLjiyz1BTSIhN17k+/FercaZBWhsRJyV0g2krbOsYVT8 9B3Rtv1QH2VqrZLMHEA2nHxMEnfrlK8NJ1O7coFWdt3Po1U1ltuNDy450Zfc3bBsPbvsg5 1AIOdDWcL0BONlPB07LxkOlQlD6aVL0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-341-5MA8H9wmOtum8LO_aKfnUg-1; Thu, 23 Mar 2023 06:59:34 -0400 X-MC-Unique: 5MA8H9wmOtum8LO_aKfnUg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CBE6185A588; Thu, 23 Mar 2023 10:59:33 +0000 (UTC) Received: from tpad.localdomain (ovpn-112-2.gru2.redhat.com [10.97.112.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A110C1121314; Thu, 23 Mar 2023 10:59:33 +0000 (UTC) Received: by tpad.localdomain (Postfix, from userid 1000) id 3D3C04038C716; Thu, 23 Mar 2023 07:52:22 -0300 (-03) Date: Thu, 23 Mar 2023 07:52:22 -0300 From: Marcelo Tosatti To: Michal Hocko Cc: Christoph Lameter , Aaron Tomlin , Frederic Weisbecker , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Russell King , Huacai Chen , Heiko Carstens , x86@kernel.org, Vlastimil Babka Subject: Re: [PATCH v7 00/13] fold per-CPU vmstats remotely Message-ID: References: <20230320180332.102837832@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 23, 2023 at 08:51:14AM +0100, Michal Hocko wrote: > On Wed 22-03-23 11:20:55, Marcelo Tosatti wrote: > > On Wed, Mar 22, 2023 at 02:35:20PM +0100, Michal Hocko wrote: > [...] > > > > "Performance details for the kworker interruption: > > > > > > > > oslat 1094.456862: sys_mlock(start: 7f7ed0000b60, len: 1000) > > > > oslat 1094.456971: workqueue_queue_work: ... function=vmstat_update ... > > > > oslat 1094.456974: sched_switch: prev_comm=oslat ... ==> next_comm=kworker/5:1 ... > > > > kworker 1094.456978: sched_switch: prev_comm=kworker/5:1 ==> next_comm=oslat ... > > > > > > > > The example above shows an additional 7us for the > > > > > > > > oslat -> kworker -> oslat > > > > > > > > switches. In the case of a virtualized CPU, and the vmstat_update > > > > interruption in the host (of a qemu-kvm vcpu), the latency penalty > > > > observed in the guest is higher than 50us, violating the acceptable > > > > latency threshold for certain applications." > > > > > > Yes, I have seen that but it doesn't really give a wider context to > > > understand why those numbers matter. > > > > OK. > > > > "In the case of RAN, a MAC scheduler with TTI=1ms, this causes >100us > > interruption observed in a guest (which is above the safety > > threshold for this application)." > > > > Is that OK? > > This might be a sufficient information for somebody familiar with the > matter (not me). So no, not enough. We need to hear a more complete > story. Michal, Please refer to https://www.diva-portal.org/smash/get/diva2:541460/FULLTEXT01.pdf 2.3 Channel Dependent Scheduling The purpose of scheduling is to decide which terminal will transmit data on which set of resource blocks with what transport format to use. The objective is to assign resources to the terminal such that the quality of service (QoS) requirement is fulfilled. Scheduling decision is taken every 1 ms by base station (termed as eNodeB) as the same length of Transmission Time Interval (TTI) in LTE system. In general: https://en.wikipedia.org/wiki/Real-time_computing Real-time computing (RTC) is the computer science term for hardware and software systems subject to a "real-time constraint", for example from event to system response.[1] Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".[2] Real-time responses are often understood to be in the order of milliseconds, and sometimes microseconds. A system not specified as operating in real time cannot usually guarantee a response within any timeframe, although typical or expected response times may be given. Real-time processing fails if not completed within a specified deadline relative to an event; deadlines must always be met, regardless of system load. For example, for the MAC scheduler processing must occur every 1ms, and a certain amount of computation takes place (and must finish before the next 1ms timeframe). A > 50us latency spike as observed by cyclictest is considered a "failure".