Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751315AbcDOUSl (ORCPT ); Fri, 15 Apr 2016 16:18:41 -0400 Received: from mail-lf0-f52.google.com ([209.85.215.52]:34066 "EHLO mail-lf0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbcDOUSk (ORCPT ); Fri, 15 Apr 2016 16:18:40 -0400 MIME-Version: 1.0 Date: Sat, 16 Apr 2016 06:18:38 +1000 Message-ID: Subject: making a COW mapping on the fly from existing vma From: Dave Airlie To: LKML , Linux Memory Management List , dri-devel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1176 Lines: 26 This was just a random thought process I was having last night, and wondered if it was possible. We have a scenario with OpenGL where certain APIs hand large amounts of data from the user to the API and when you return from the API call the user can then free/overwrite/do whatever they want with the data they gave you, which pretty much means you have to straight away process the data. Now there have been attempts at threading the GL API, but one thing they usually hit is they have to do a lot of unthreaded processing for these scenarios, so I was wondering could we do some COW magic with the data. More than likely the data will be anonymous mappings though maybe some filebacked, and my idea would be you'd in the main thread create a new readonly VMA from the old pages and set the original mapping to do COW on all of its pages. Then the thread would pick up the readonly VMA mapping and do whatever background processing it wants while the main thread continues happily on its way. I'm not sure if anyone who's done glthread has thought around this, or if the kernel APIs are in place to do something like this so I just thought I'd throw it out there. Dave.