On Tue, 25 Oct 2022, Andrew Morton wrote:
> On Tue, 25 Oct 2022 11:03:38 +0100 Mel Gorman
> wrote:
>
> > > If so I
> > > can temporarily put it in until it arrives via the next rc - assuming that
> > > would be the flow from upstream pov?
> > >
> >
> > I expect it to. It's currently in the akp
> > Thanks for the report. As shmem pages pages are allocated via
> > > vma_alloc_folio
> > > and are compound pages, can you try the following patch please? If it
> > > still triggers, please post the new oops as it'll include the tail page
> > >
On Thu, 16 Sep 2021, Jani Nikula wrote:
> On Thu, 16 Sep 2021, Tvrtko Ursulin wrote:
> > On 16/09/2021 05:37, Hugh Dickins wrote:
> >> Two Lenovo ThinkPads, old T420s (2011), newer X1 Carbon 5th gen (2017):
> >> i915 working fine on both up to 5.14, but blank screens bo
On Thu, 8 Aug 2019, Chris Wilson wrote:
> + * By creating our own shmemfs mountpoint, we can pass in
> + * mount flags that better match our usecase.
> + *
> + * One example, although it is probably better with a per-file
> + * control, is selecting huge page allocations ("
On Thu, 8 Aug 2019, Al Viro wrote:
> On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > Though personally I'm averse to managing "f"objects through
> > > "
On Mon, 5 Aug 2019, Al Viro wrote:
> On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > > tmpfs does not set ->remount_fs() anymore and its users need
> > > to be converted to new mount API.
> >
> > Could you explain
On Wed, 23 Nov 2016, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 09:26:11PM -0800, Hugh Dickins wrote:
> > On Tue, 22 Nov 2016, Matthew Auld wrote:
> > > On 9 November 2016 at 18:36, Hugh Dickins wrote:
> > > > On Wed, 9 Nov 2016, Daniel Vetter wrote:
>
On Tue, 22 Nov 2016, Matthew Auld wrote:
> On 9 November 2016 at 18:36, Hugh Dickins wrote:
> > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> >>
> >> Hi all -mm folks!
> >>
> >> Any feedback on these two? It's kinda an intermediate step towards a
On Mon, 14 Nov 2016, akash goel wrote:
> On Thu, Nov 10, 2016 at 1:00 PM, Goel, Akash wrote:
> > On 11/10/2016 12:09 PM, Hugh Dickins wrote:
> >> On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
> >>> @@ -4185,6 +4189,8 @@ struct drm_i915_gem_object *
> >
ifier
>
> v6:
> - Remove i915_gem_object_get/put across unsafe_drop_pages() as with
> struct_mutex protection object can't disappear. (Chris)
>
> Testcase: igt/gem_shrink
> Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
> Cc: Hugh Dickins
> Cc:
this, and sorry for all my delay.
>
> v2:
> - Drop dev_ prefix from the members of shmem_dev_info structure. (Joonas)
> - Change the return type of shmem_set_device_op() to void and remove the
> check for pre-existing data. (Joonas)
> - Rename shmem_set_device_op() to shmem_set_dev_
On Wed, 9 Nov 2016, Daniel Vetter wrote:
>
> Hi all -mm folks!
>
> Any feedback on these two? It's kinda an intermediate step towards a
> full-blown gemfs, and I think useful for that. Or do we need to go
> directly to our own backing storage thing? Aside from ack/nack from -mm I
> think this is
pdrm, crestline, broadwater) require zone DMA32
if there's more than 4GB of ram.
Fixes: 800d8c63b2e9 ("shmem: add huge pages support")
Cc: sta...@vger.kernel.org # v4.8
Signed-off-by: Hugh Dickins
---
mm/shmem.c |2 ++
1 file changed, 2 insertions(+)
--- 4.9-rc4/mm/shmem.c
On Wed, 27 Apr 2016, Kirill A. Shutemov wrote:
> On Tue, Apr 26, 2016 at 02:53:41PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 25, 2016 at 02:42:50AM +0300, Kirill A. Shutemov wrote:
> > > On Mon, Apr 04, 2016 at 02:18:10PM +0100, Chris Wilson wrote:
> > > > From: Akash Goel
> > > >
> > > > This
ldpage = newpage;
> } else {
> - mem_cgroup_migrate(oldpage, newpage, false);
> + mem_cgroup_migrate(oldpage, newpage, true);
> lru_cache_add_anon(newpage);
> *pagep = newpage;
> }
Acked-by: Hugh Dickins
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
rtual address by the previous stub failed the
PageHighMem test, and so did no harm.
Signed-off-by: Hugh Dickins
---
drivers/gpu/drm/i915/i915_gem_render_state.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 3.16-rc/drivers/gpu/drm/i915/i915_gem_render_state.c2014-06-16
16 matches
Mail list logo
