From owner-svn-src-all@freebsd.org Wed Oct 7 06:15:00 2015 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 316EE9D0E25; Wed, 7 Oct 2015 06:15:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE50D255; Wed, 7 Oct 2015 06:14:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t976Erwk037773 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Oct 2015 09:14:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t976Erwk037773 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t976ErhI037772; Wed, 7 Oct 2015 09:14:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Oct 2015 09:14:53 +0300 From: Konstantin Belousov To: Jean-S??bastien P??dron Cc: s3erios@gmail.com, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288653 - in head/sys/dev/drm2: . i915 Message-ID: <20151007061453.GH2257@kib.kiev.ua> References: <201510040745.t947jbp7082807@repo.freebsd.org> <20151004094649.GG11284@kib.kiev.ua> <56142CCC.7000807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56142CCC.7000807@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 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: Wed, 07 Oct 2015 06:15:00 -0000 On Tue, Oct 06, 2015 at 10:19:24PM +0200, Jean-S??bastien P??dron wrote: > On 04.10.2015 11:46, Konstantin Belousov wrote: > > On Sun, Oct 04, 2015 at 07:45:37AM +0000, Adrian Chadd wrote: > >> * Add missing case statement (gen == 3) in intel_gpu_reset(). > > This seems to be wrong. The i915 and G33 chipsets do not have registers > > declared in the 8xx chipset documentation. More, i915 and G33 have different > > reset procedures. > > > > The absence of '3' case was copied from the corresponding Linux kernel. > > Was this change tested, or is there a reference to upstream where the > > handling was added in this manner ? > > You're right, even in Linux 3.8, the switch does not have a case for > generation 3. > > >> * Replace M_WAITOK with M_NOWAIT when the return value of malloc is checked (may be incorrect). > > This is also incorrect. At least the modesetting pathes are executed in > > the syscall context, and sleeping is allowed; the modesetting locks were > > selected to make sleeping possible. Using nowait causes random syscalls > > failure where the requests would succeed otherwise. > > My reasoning was that M_WAITOK could make the display hang/unresponsive > while the memory is under pressure. The caller should be responsible for > handling the error instead. The majority of the calls changed were for the modesetting. In other words, the failures would probably affect only setup path, and probably leave the display in half-configured state. That said, hang is not the expected outcome of M_WAITOK behaviour. M_WAITOK indeed prevents real-time, but it only causes hang in case of memory deadlock. M_NOWAIT should only be used in contexts where sleepable wait for memory or address space is impossible or causes a damage to the managed hardware. > > In Linux, *alloc() calls may fail so application should already be > responsible for that. I believe there are subtle differences between our- and Linux- nowait behaviour. I claim (but do not want to take liability of prove it with references to Linux code) that our M_NOWAIT may fail transiently due to pagedaemon not keeping up with load, while Linux top-half nowait alloc only fails for real out-of-resources conditions. What I am trying to say, leave M_NOWAIT out of syscalls. Some time ago M_NOWAIT also means that the caller is allowed to use reserves to satisfy allocation, but this was fixed.