Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 15 1月, 2013 1 次提交
  3. 11 1月, 2013 1 次提交
    • D
      drm/i915: Revert shrinker changes from "Track unbound pages" · 93927ca5
      由 Daniel Vetter 提交于 
      This partially reverts

commit 6c085a72
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 20 11:40:46 2012 +0200

    drm/i915: Track unbound pages

Closer inspection of that patch revealed a bunch of unrelated changes
in the shrinker:
- The shrinker count is now in pages instead of objects.
- For counting the shrinkable objects the old code only looked at the
  inactive list, the new code looks at all bounds objects (including
  pinned ones). That is obviously in addition to the new unbound list.
- The shrinker cound is no longer scaled with
  sysctl_vfs_cache_pressure. Note though that with the default tuning
  value of vfs_cache_pressue = 100 this doesn't affect the shrinker
  behaviour.
- When actually shrinking objects, the old code first dropped
  purgeable objects, then normal (inactive) objects. Only then did it,
  in a last-ditch effort idle the gpu and evict everything. The new
  code omits the intermediate step of evicting normal inactive
  objects.

Safe for the first change, which seems benign, and the shrinker count
scaling, which is a bit a different story, the endresult of all these
changes is that the shrinker is _much_ more likely to fall back to the
last-ditch resort of idling the gpu and evicting everything.  The old
code could only do that if something else evicted lots of objects
meanwhile (since without any other changes the nr_to_scan will be
smaller than the object count).

Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only
dentry/inode object caches should scale their shrinker counts with
vfs_cache_pressure. Originally I've had that change reverted, too. But
Chris Wilson insisted that it's too bogus and shouldn't again see the
light of day.

Hence revert all these other changes and restore the old shrinker
behaviour, with the minor adjustment that we now first scan the
unbound list, then the inactive list for each object category
(purgeable or normal).

A similar patch has been tested by a few people affected by the gen4/5
hangs which started to appear in 3.7, which some people bisected to
the "drm/i915: Track unbound pages" commit. But just disabling the
unbound logic alone didn't change things at all.

Note that this patch doesn't fix the referenced bugs, it only hides
the underlying bug(s) well enough to restore pre-3.7 behaviour. The
key to achieve that is to massively reduce the likelyhood of going
into a full gpu stall and evicting everything.

v2: Reword commit message a bit, taking Chris Wilson's comment into
account.

v3: On Chris Wilson's insistency, do not reinstate the rather bogus
vfs_cache_pressure change.
Tested-by: NGreg KH <gregkh@linuxfoundation.org>
Tested-by: NDave Kleikamp <dave.kleikamp@oracle.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
References: https://bugs.freedesktop.org/show_bug.cgi?id=57122
References: https://bugs.freedesktop.org/show_bug.cgi?id=56916
References: https://bugs.freedesktop.org/show_bug.cgi?id=57136
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      93927ca5
  5. 09 1月, 2013 2 次提交
  7. 08 1月, 2013 3 次提交
  9. 07 1月, 2013 2 次提交
  11. 03 1月, 2013 1 次提交
    • J
      leds: leds-gpio: set devm_gpio_request_one() flags param correctly · 2d7c22f6
      由 Javier Martinez Canillas 提交于 
      commit a99d76f9 leds: leds-gpio: use gpio_request_one

changed the leds-gpio driver to use gpio_request_one() instead
of gpio_request() + gpio_direction_output()

Unfortunately, it also made a semantic change that breaks the
leds-gpio driver.

The gpio_request_one() flags parameter was set to:

GPIOF_DIR_OUT | (led_dat->active_low ^ state)

Since GPIOF_DIR_OUT is 0, the final flags value will just be the
XOR'ed value of led_dat->active_low and state.

This value were used to distinguish between HIGH/LOW output initial
level and call gpio_direction_output() accordingly.

With this new semantic gpio_request_one() will take the flags value
of 1 as a configuration of input direction (GPIOF_DIR_IN) and will
call gpio_direction_input() instead of gpio_direction_output().

int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
{
..
	if (flags & GPIOF_DIR_IN)
		err = gpio_direction_input(gpio);
	else
		err = gpio_direction_output(gpio,
				(flags & GPIOF_INIT_HIGH) ? 1 : 0);
..
}

The right semantic is to evaluate led_dat->active_low ^ state and
set the output initial level explicitly.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reported-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>
      2d7c22f6
  13. 02 1月, 2013 4 次提交
  15. 30 12月, 2012 7 次提交
  17. 27 12月, 2012 6 次提交
  19. 24 12月, 2012 1 次提交
    • R
      Partly revert "[media] uvcvideo: Set error_idx properly for extended controls API failures" · 9c016d61
      由 Rafael J. Wysocki 提交于 
      Commit f0ed2ce8 ("[media] uvcvideo: Set error_idx properly for
extended controls API failures") causes user space to behave incorrectly
on one of my test machines (there is no sound under KDE 4.9.4 using
pulseaudio and there is a knotify4 process occupying one of the CPU
cores 100% of the time).  Reverting that commit entirely fixes the
problem for me.

However, commit f0ed2ce8 appears to do more than it follows from its
changelog, because the changelog only says about the changes related to
ctrls->error_idx, while the commit additionally changes error codes
returned by various functions in uvc_ctrl.c and uvc_v4l2.c.  It turns
out that the changes of the returned error codes confuse the user spce,
so it is sufficient to revert the part of commit f0ed2ce8 not
mentioned in its changelog to fix the problem.

[ 'ENOENT' is not a valid error return from an ioctl to begin with, and
  I don't understand how anybody ever even thought it would be.  - Linus ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c016d61
  21. 23 12月, 2012 9 次提交
  23. 22 12月, 2012 3 次提交