From owner-svn-src-all@freebsd.org Thu Nov 30 21:38:44 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74F39DBBA6E; Thu, 30 Nov 2017 21:38:44 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01161776CB; Thu, 30 Nov 2017 21:38:43 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f42.google.com with SMTP id f18so9516495lfg.8; Thu, 30 Nov 2017 13:38:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ckx82LY2hKLvfMFQAeFjJaVZofK/w8ksQFc0jfEFt/4=; b=l/QHShdVSgxN6q1w7pzSNhurTXlY2TUyK3QB8zn+hbgU5QCCE7wAsZWxGZ5d0+yEhK nVsMWtSvB0dG+WJB2vCkUQcOPjvql0iuaf9spHPOjrEYXbZRpRXm7NWcE0rPBbfjex+F /rkHNcmdPslvauhzVHMhLb7cb6Ou9TXyxHtGiFPJQH8Ua/43rK3IdYQ9aetf0CMl/2Ze tMfRDbPbJcGZBidc3yJRq17Dq4T+SFwudGW5+9s0QmVEZw7xPqf87NJarrnoafpLwyAr xvmRDLR6yaiMnrXd8fgO9j2YmAyMBaZnl8S2lUcRAS0tm34K6v4Vtvl1YeXL+N6YkPRO x1hg== X-Gm-Message-State: AJaThX42EwudKYT9mQcLrt5VkTD8e9dqVa4tt4iiZI/Uz3zOYf5fEnYH xzNDIFhuP/mvkfcWk2z/ol5WjFoo0Iw= X-Google-Smtp-Source: AGs4zMYWdbkgrH83W9P4PCGrM8PrWGZnGznpaZpk4/s0HdaPwu0smsvg2jlYmxGFLaczn9g8aneeVA== X-Received: by 10.46.82.132 with SMTP id n4mr3914311lje.31.1512077525597; Thu, 30 Nov 2017 13:32:05 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id n67sm1018319lja.44.2017.11.30.13.32.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 13:32:04 -0800 (PST) Subject: Re: svn commit: r326383 - head/sys/x86/cpufreq To: Jung-uk Kim , cem@freebsd.org Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201711300140.vAU1e7dC001292@repo.freebsd.org> <31ee136d-164e-bb9b-3a90-71bb7f55595a@FreeBSD.org> From: Andriy Gapon Message-ID: <520347e8-1539-6a11-b93c-4934d825a272@FreeBSD.org> Date: Thu, 30 Nov 2017 23:32:02 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <31ee136d-164e-bb9b-3a90-71bb7f55595a@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 21:38:44 -0000 On 30/11/2017 22:47, Jung-uk Kim wrote: > On 11/30/2017 15:31, Conrad Meyer wrote: >> On Thu, Nov 30, 2017 at 12:08 PM, Jung-uk Kim wrote: >>> On 11/30/2017 14:32, Conrad Meyer wrote: >>>> Hi, >>>> >>>> I don't think this answers the second question about the conditional. >>>> It seems like PCPU_GET() for the initial CPU should be pulled out of >>>> the loop, which binds the thread to a different CPU every iteration. >>> >>> Ah, good catch. I'll fix it soon. Sorry. >> >> Thanks! :-) >> >>>> Also, as a side effect of disabling verification, you have fixed PR >>>> 221621, 219213, and probably 218262. >>> >>> Probably. However, I am just trying to fix my FX-8350 and A10-6800 and >>> I don't have Zen processors to verify the MSRs are actually working on >>> those CPUs. >> >> I have one, I can verify if needed (although the change looks good to >> me). On some Zen systems (including mine) it seems that the hardware >> can successfully set a P-state, but will fail to read it back. For me >> it is P1 but other users have reported P0. That's the root issue of >> all of those PRs. If reading back isn't required, maybe that's a >> solution to the issue. > > Reading back was not really necessary (aka "fire-and-forget"). However, > we wanted to make sure all cores are in the same P-state before > returning to the caller. Back in the days, it wasn't a big deal because > we only had few cores to deal with and never expected to see complex > topologies such as the Threadripper, I guess. :-/ I have not revisited cpufreq in a long time, so I can say something silly. But I think that we need to finally start being aware of power state dependencies (ACPI _PSD). I have an impression that a good share of the problems was (perhaps still is) because we completely ignored that stuff. I mean that if a platform tells us that CPUs in a given domain would transition to a certain state only after we instruct all of them to go to that state, then it is wrong of us to expect that after instructing just one CPU it would transition to that state. -- Andriy Gapon