[PATCH 0/9] drm/i915/gvt: Refine the gtt shadowing

[Zhi Wang]

That's not my purpose. What we are talking about is the right direction. 
You said it's a bad idea, but you just give me another answer of another 
problem. It's quite confusing. It's just like you want to refuse 
something instead of discussion. I just want to clarify what is good and 
what it's bad. That's the point. It's not implementation.


On 12/26/17 11:05, Du, Changbin wrote:
> On Mon, Dec 25, 2017 at 09:15:03PM +0800, Zhi Wang wrote:
>> Besides, the right way of thinking to figure out the problem is we have to
>> know the right direction, right? If we think we cannot do this because of
>> efforts and time, like what you said, the customer might enable it, then we
>> got challenged by Linus. I mean if the situation you describe really
>> happens, it means we *didn't* do a good job to implement the memory
>> shrinker. It *doesn't* mean the memory shrinker is the wrong direction. You
>> see they are two different problems, one is practical, one is direction.
>> Please do figure out the difference between *two* problems.
>>
> If you think that fit your purpose, you can implement it and Cc mm maillist to
> get more comments. This way can rduce the risk. The task itself is simple.
>
>   
>> Thanks,
>> Zhi.
>>
>> On 12/25/17 18:45, Zhi Wang wrote:
>>> Yes. But we need a correct re-claim path even the customer will report
>>> it right?
>>>
>>> Thanks,
>>> Zhi.
>>>
>>> On 12/25/17 18:35, Du, Changbin wrote:
>>>> On Mon, Dec 25, 2017 at 06:22:47PM +0800, Zhi Wang wrote:
>>>>> I think it's a good idea because i915 has done that already and
>>>>> the current
>>>>> shadow page reclaim path is actually just a simple workaround.
>>>>> The right way
>>>>> to re-claim pages is from memory shrinker. For being challenged, I think
>>>>> it's OK because the memory shrinker will only be registered when GVT is
>>>>> enabled.
>>>>>
>>>> Even though the shrinker can only be enabled if GVTg is active, but
>>>> the custom
>>>> can report such bug to mm mailist. Some mechanism that expose memory
>>>> management
>>>> control to out of VM subsystem already be asked by Linus several times.
>>>>
>>>>> On 12/25/17 18:10, Du, Changbin wrote:
>>>>>> On Mon, Dec 25, 2017 at 06:02:21PM +0800, Zhi Wang wrote:
>>>>>>> BTW: Since we allocate a lot of pages from system
>>>>>>> memory, we might need a
>>>>>>> memory shrinker here. If you are interested, you can ask
>>>>>>> Hang to add an task
>>>>>>> item for you in the next Q.
>>>>>> It is not a good idea to do this at device driver.(at least
>>>>>> not prefored).
>>>>>> Because we need be very careful since it is called from
>>>>>> Linux VM directly.
>>>>>> If GVTg's bug breaks VM we will be challenged by Linus.
>>>>>>> Actually I think splitting ppgtt and ggtt in names is
>>>>>>> also a good idea.The
>>>>>>> history I can remember is Kevin wants they looks the
>>>>>>> same from high level
>>>>>>> calls during the patch of BDW enabling. In the first
>>>>>>> patch series they were
>>>>>>> separated, also another APIs like *get_mm_*.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Zhi.
>>>>>>>
>>>>>>> On 12/25/17 17:11, changbin.du at intel.com wrote:
>>>>>>>> From: Changbin Du <changbin.du at intel.com>
>>>>>>>>
>>>>>>>> This is the first part of patch set "drm/i915/gvt:
>>>>>>>> Add support for huge gtt (2M/64K)".
>>>>>>>> The GTT related code are refined. I just need a
>>>>>>>> clean code base to add new
>>>>>>>> feature.
>>>>>>>>
>>>>>>>> patch #1 and #7 are fat patch, please take care.
>>>>>>>>
>>>>>>>> Changbin Du (9):
>>>>>>>>       drm/i915/gvt: Rework shadow graphic memory management code
>>>>>>>>       drm/i915/gvt: Add verbose gtt shadow logs
>>>>>>>>       drm/i915/gvt: Rename ggtt related functions to be more specific
>>>>>>>>       drm/i915/gvt: Factor out
>>>>>>>>         intel_vgpu_{get_or_create_ppgtt_mm,find_destroy_ppgtt_mm}
>>>>>>>> interfaces
>>>>>>>>       drm/i915/gvt: Use standard pte bit definition
>>>>>>>>       drm/i915/gvt: Refine pte shadowing process
>>>>>>>>       drm/i915/gvt: Rework shadow page management code
>>>>>>>>       drm/i915/gvt: Manage shadow pages with radix tree
>>>>>>>>       drm/i915/gvt: Define PTE addr mask with GENMASK_ULL
>>>>>>>>
>>>>>>>>      drivers/gpu/drm/i915/gvt/Makefile     |    2 +-
>>>>>>>>      drivers/gpu/drm/i915/gvt/gtt.c        | 1427
>>>>>>>> +++++++++++++++------------------
>>>>>>>>      drivers/gpu/drm/i915/gvt/gtt.h        |  182 ++---
>>>>>>>>      drivers/gpu/drm/i915/gvt/gvt.c        |    2 +-
>>>>>>>>      drivers/gpu/drm/i915/gvt/gvt.h        |    2 +
>>>>>>>>      drivers/gpu/drm/i915/gvt/handlers.c   |   18 +-
>>>>>>>>      drivers/gpu/drm/i915/gvt/mmio.c       |    9 +-
>>>>>>>>      drivers/gpu/drm/i915/gvt/mpt.h        |   36 +-
>>>>>>>>      drivers/gpu/drm/i915/gvt/page_track.c |  181 +++++
>>>>>>>>      drivers/gpu/drm/i915/gvt/page_track.h |   54 ++
>>>>>>>>      drivers/gpu/drm/i915/gvt/scheduler.c  |   48 +-
>>>>>>>>      drivers/gpu/drm/i915/gvt/trace.h      |   38 +-
>>>>>>>>      drivers/gpu/drm/i915/gvt/vgpu.c       |    1 +
>>>>>>>>      13 files changed, 1002 insertions(+), 998 deletions(-)
>>>>>>>>      create mode 100644 drivers/gpu/drm/i915/gvt/page_track.c
>>>>>>>>      create mode 100644 drivers/gpu/drm/i915/gvt/page_track.h
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> intel-gvt-dev mailing list
>>>>>>> intel-gvt-dev at lists.freedesktop.org
>>>>>>> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev