Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp457629ybe; Thu, 5 Sep 2019 00:09:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwx65MQ7GqAH2Rat2kbrS4G7Ax+yUmBt76j2toeEB+dkv3MkvulWHsnqfgomtGpzgYGCP/b X-Received: by 2002:a17:90a:b118:: with SMTP id z24mr2257399pjq.79.1567667361542; Thu, 05 Sep 2019 00:09:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567667361; cv=none; d=google.com; s=arc-20160816; b=ew5kxI9FUre9qCUwTCwCHb98gcyTdtUaJBWcY10YDSCFOs2kccCKka0/mhNBocPxYa XATL2CTgEdJ5bdUBQaghXQOrOWA4Q6gOeHeTHDaxswT/fy8CyBRIHLnVze+PFFCdotz8 wtb4N+dqqCUE6JdKYWyN+nlp7I0KfINJVEeUUS3Wax/ASR0jXH0VFuwtgkAzkmq12hHA +/x5GiDdF4ZgOkmLsrM8Zvjvf+HufsGKrfM6QSClBgPpQo6pdMSKNEy+T6aQH1qCObE3 qRrXPqH9CfQGnR7hbtHYA7UcDocG5EIaIzUOFPyUANimXGeA7qGMXehW8kwbzxxk5o/i 3XEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=IXm3bfOPPV6PPrc7vFPatEhgFLZinPLr56BANcYX9Ng=; b=K+wtAQ8GjZp8AEtCEyFd1j9c2snY4jqLMex2uXww8SXREl4qusK3cLm/x8hCawQ5cf dQ62q2WJ2YQf05y7fxT+6Xh1ML7ocrfbhLrtznHVZlwO2A6nQoCrGyVb1nVdfsk0BYyn Sg3k6aAU3V3puzmnQmszYUihuHrjrQt+32Onnq0yXvJxiPDtxqxSeBOcPNlhyb+ovTRa K/mJUWle3VQIYEf89pOxnaEbxT71Xxi7Du2ottXEjae8duzs6Ur42K1TQsZj8aPjoA4k JT0MJHyehdBJFlpFXsaxsFR1+QVTyPM6Nm1neauTVX+CwZI8/5LXQ0IOpMwn2E93g7OK LR9Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p35si974161pgb.484.2019.09.05.00.09.05; Thu, 05 Sep 2019 00:09:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731501AbfIEG6y (ORCPT + 99 others); Thu, 5 Sep 2019 02:58:54 -0400 Received: from mga17.intel.com ([192.55.52.151]:49525 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731065AbfIEG6y (ORCPT ); Thu, 5 Sep 2019 02:58:54 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2019 23:58:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,469,1559545200"; d="scan'208";a="185358483" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.147.113]) by orsmga003.jf.intel.com with ESMTP; 04 Sep 2019 23:58:51 -0700 Date: Thu, 5 Sep 2019 14:59:17 +0800 From: Feng Tang To: Daniel Vetter Cc: Dave Airlie , Stephen Rothwell , Rong Chen , Michel =?utf-8?Q?D=C3=A4nzer?= , Linux Kernel Mailing List , dri-devel , Thomas Zimmermann , LKP Subject: Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression Message-ID: <20190905065917.GE5541@shbuild999.sh.intel.com> References: <44029e80-ba00-8246-dec0-fda122d53f5e@suse.de> <90e78ce8-d46a-5154-c324-a05aa1743c98@intel.com> <2e1b4d65-d477-f571-845d-fa0a670859af@suse.de> <20190904062716.GC5541@shbuild999.sh.intel.com> <72c33bf1-9184-e24a-c084-26d9c8b6f9b7@suse.de> <20190904083558.GD5541@shbuild999.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vetter, On Wed, Sep 04, 2019 at 01:20:29PM +0200, Daniel Vetter wrote: > On Wed, Sep 4, 2019 at 1:15 PM Dave Airlie wrote: > > > > On Wed, 4 Sep 2019 at 19:17, Daniel Vetter wrote: > > > > > > On Wed, Sep 4, 2019 at 10:35 AM Feng Tang wrote: > > > > > > > > Hi Daniel, > > > > > > > > On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote: > > > > > On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote: > > > > > > > > > > > > Hi > > > > > > > > > > > > Am 04.09.19 um 08:27 schrieb Feng Tang: > > > > > > >> Thank you for testing. But don't get too excited, because the patch > > > > > > >> simulates a bug that was present in the original mgag200 code. A > > > > > > >> significant number of frames are simply skipped. That is apparently the > > > > > > >> reason why it's faster. > > > > > > > > > > > > > > Thanks for the detailed info, so the original code skips time-consuming > > > > > > > work inside atomic context on purpose. Is there any space to optmise it? > > > > > > > If 2 scheduled update worker are handled at almost same time, can one be > > > > > > > skipped? > > > > > > > > > > > > To my knowledge, there's only one instance of the worker. Re-scheduling > > > > > > the worker before a previous instance started, will not create a second > > > > > > instance. The worker's instance will complete all pending updates. So in > > > > > > some way, skipping workers already happens. > > > > > > > > > > So I think that the most often fbcon update from atomic context is the > > > > > blinking cursor. If you disable that one you should be back to the old > > > > > performance level I think, since just writing to dmesg is from process > > > > > context, so shouldn't change. > > > > > > > > Hmm, then for the old driver, it should also do the most update in > > > > non-atomic context? > > > > > > > > One other thing is, I profiled that updating a 3MB shadow buffer needs > > > > 20 ms, which transfer to 150 MB/s bandwidth. Could it be related with > > > > the cache setting of DRM shadow buffer? say the orginal code use a > > > > cachable buffer? > > > > > > Hm, that would indicate the write-combining got broken somewhere. This > > > should definitely be faster. Also we shouldn't transfer the hole > > > thing, except when scrolling ... > > > > First rule of fbcon usage, you are always effectively scrolling. > > > > Also these devices might be on a PCIE 1x piece of wet string, not sure > > if the numbers reflect that. > > pcie 1x 1.0 is 250MB/s, so yeah with a bit of inefficiency and > overhead not entirely out of the question that 150MB/s is actually the > hw limit. If it's really pcie 1x 1.0, no idea where to check that. > Also might be worth to double-check that the gpu pci bar is listed as > wc in debugfs/x86/pat_memtype_list. Here is some dump of the device info and the pat_memtype_list, while it is running other 0day task: controller info ================= 03:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation MGA G200e [Pilot] ServerEngines (SEP1) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort+ SERR- Capabilities: [144 v1] Vendor Specific Information: ID=0004 Rev=1 Len=03c Capabilities: [1d0 v1] Vendor Specific Information: ID=0003 Rev=1 Len=00a Capabilities: [250 v1] #19 Capabilities: [280 v1] Vendor Specific Information: ID=0005 Rev=3 Len=018 Capabilities: [298 v1] Vendor Specific Information: ID=0007 Rev=0 Len=024 Thanks, Feng > > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch