| Message ID | 20200219203544.31013-1-ville.syrjala@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: Put drm_display_mode on diet | expand |
On Wed, Feb 19, 2020 at 10:35:32PM +0200, Ville Syrjala wrote:
> - Eliminate the second list head somehow?
I think we could just convert that to a boolean, or even just
borrow eg. the one totally free mode->type bit for our internal
use to tag the exposed modes. That would in fact get us down
to 120 bytes on 64bit machines (and 112 bytes on 32bit).
The downside would be one extra loop over the modes in the
getconnector ioctl to clear the stale tags.
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > struct drm_display_mode is extremely fat. Put it on diet. > > Some stats for the whole series: > > 64bit sizeof(struct drm_display_mode): > 200 -> 136 bytes (-32%) > > 64bit bloat-o-meter -c drm.ko: > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) > Function old new delta > ... > Total: Before=189430, After=188779, chg -0.34% > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > Data old new delta > Total: Before=11667, After=11667, chg +0.00% > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > RO Data old new delta > edid_4k_modes 1000 680 -320 > edid_est_modes 3400 2312 -1088 > edid_cea_modes_193 5400 3672 -1728 > drm_dmt_modes 17600 11968 -5632 > edid_cea_modes_1 25400 17272 -8128 > Total: Before=71239, After=54343, chg -23.72% > > > 64bit bloat-o-meter drm.ko: > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547) > ... > Total: Before=272336, After=254789, chg -6.44% > > > 32bit sizeof(struct drm_display_mode): > 184 -> 120 bytes (-34%) > > 32bit bloat-o-meter -c drm.ko > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625) > Function old new delta > ... > Total: Before=172359, After=171734, chg -0.36% > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > Data old new delta > Total: Before=4227, After=4227, chg +0.00% > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > RO Data old new delta > edid_4k_modes 920 600 -320 > edid_est_modes 3128 2040 -1088 > edid_cea_modes_193 4968 3240 -1728 > drm_dmt_modes 16192 10560 -5632 > edid_cea_modes_1 23368 15240 -8128 > Total: Before=59230, After=42334, chg -28.53% > > 32bit bloat-o-meter drm.ko: > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521) > ... > Total: Before=235816, After=218295, chg -7.43% > > > Some ideas for further reduction: > - Convert mode->name to a pointer (saves 24/28 bytes in the > struct but would often require a heap alloc for the name (though > typical mode name is <10 bytes so still overall win perhaps) > - Get rid of mode->name entirely? I guess setcrtc & co. is the only > place where we have to preserve the user provided name, elsewhere > could pehaps just generate on demand? Not sure how tricky this > would get. The series does some great work, with future work reaching the cache line for 64bit. Doing much more than that might be an overkill IMHO. In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there, avoiding the heap alloc/calc on demand fun. While also ensuring the name is sufficiently large for the next decade or so. From drm_mode_set_name(): snprintf(mode->name, DRM_DISPLAY_MODE_LEN, "%dx%d%s", mode->hdisplay, mode->vdisplay, interlaced ? "i" : ""); We change the h/v display from (10^15)-1 to (10^11)-1 which seems reasonable. Note: haven't checked if name includes the terminating \0, so take numbers with a grain of salt. -Emil
On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote: > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala > <ville.syrjala@linux.intel.com> wrote: > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > struct drm_display_mode is extremely fat. Put it on diet. > > > > Some stats for the whole series: > > > > 64bit sizeof(struct drm_display_mode): > > 200 -> 136 bytes (-32%) > > > > 64bit bloat-o-meter -c drm.ko: > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) > > Function old new delta > > ... > > Total: Before=189430, After=188779, chg -0.34% > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > Data old new delta > > Total: Before=11667, After=11667, chg +0.00% > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > RO Data old new delta > > edid_4k_modes 1000 680 -320 > > edid_est_modes 3400 2312 -1088 > > edid_cea_modes_193 5400 3672 -1728 > > drm_dmt_modes 17600 11968 -5632 > > edid_cea_modes_1 25400 17272 -8128 > > Total: Before=71239, After=54343, chg -23.72% > > > > > > 64bit bloat-o-meter drm.ko: > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547) > > ... > > Total: Before=272336, After=254789, chg -6.44% > > > > > > 32bit sizeof(struct drm_display_mode): > > 184 -> 120 bytes (-34%) > > > > 32bit bloat-o-meter -c drm.ko > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625) > > Function old new delta > > ... > > Total: Before=172359, After=171734, chg -0.36% > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > Data old new delta > > Total: Before=4227, After=4227, chg +0.00% > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > RO Data old new delta > > edid_4k_modes 920 600 -320 > > edid_est_modes 3128 2040 -1088 > > edid_cea_modes_193 4968 3240 -1728 > > drm_dmt_modes 16192 10560 -5632 > > edid_cea_modes_1 23368 15240 -8128 > > Total: Before=59230, After=42334, chg -28.53% > > > > 32bit bloat-o-meter drm.ko: > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521) > > ... > > Total: Before=235816, After=218295, chg -7.43% > > > > > > Some ideas for further reduction: > > - Convert mode->name to a pointer (saves 24/28 bytes in the > > struct but would often require a heap alloc for the name (though > > typical mode name is <10 bytes so still overall win perhaps) > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only > > place where we have to preserve the user provided name, elsewhere > > could pehaps just generate on demand? Not sure how tricky this > > would get. > > The series does some great work, with future work reaching the cache > line for 64bit. > Doing much more than that might be an overkill IMHO. > > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there, > avoiding the heap alloc/calc on demand fun. > While also ensuring the name is sufficiently large for the next decade or so. Unfortunately it's part of the uabi. So can't change it without some risk of userspace breakage. The least demanding option is probably to nuke export_head. We need one bit to replace it, which we can get by either: - stealing from eg. mode->type, or perhaps mode->private_flags - nuke private_flags outright and replace it with a bool for this purpose
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote: > On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala > > <ville.syrjala@linux.intel.com> wrote: > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > struct drm_display_mode is extremely fat. Put it on diet. > > > > > > Some stats for the whole series: > > > > > > 64bit sizeof(struct drm_display_mode): > > > 200 -> 136 bytes (-32%) > > > > > > 64bit bloat-o-meter -c drm.ko: > > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) > > > Function old new delta > > > ... > > > Total: Before=189430, After=188779, chg -0.34% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=11667, After=11667, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes 1000 680 -320 > > > edid_est_modes 3400 2312 -1088 > > > edid_cea_modes_193 5400 3672 -1728 > > > drm_dmt_modes 17600 11968 -5632 > > > edid_cea_modes_1 25400 17272 -8128 > > > Total: Before=71239, After=54343, chg -23.72% > > > > > > > > > 64bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547) > > > ... > > > Total: Before=272336, After=254789, chg -6.44% > > > > > > > > > 32bit sizeof(struct drm_display_mode): > > > 184 -> 120 bytes (-34%) > > > > > > 32bit bloat-o-meter -c drm.ko > > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625) > > > Function old new delta > > > ... > > > Total: Before=172359, After=171734, chg -0.36% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=4227, After=4227, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes 920 600 -320 > > > edid_est_modes 3128 2040 -1088 > > > edid_cea_modes_193 4968 3240 -1728 > > > drm_dmt_modes 16192 10560 -5632 > > > edid_cea_modes_1 23368 15240 -8128 > > > Total: Before=59230, After=42334, chg -28.53% > > > > > > 32bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521) > > > ... > > > Total: Before=235816, After=218295, chg -7.43% > > > > > > > > > Some ideas for further reduction: > > > - Convert mode->name to a pointer (saves 24/28 bytes in the > > > struct but would often require a heap alloc for the name (though > > > typical mode name is <10 bytes so still overall win perhaps) > > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only > > > place where we have to preserve the user provided name, elsewhere > > > could pehaps just generate on demand? Not sure how tricky this > > > would get. > > > > The series does some great work, with future work reaching the cache > > line for 64bit. > > Doing much more than that might be an overkill IMHO. > > > > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there, > > avoiding the heap alloc/calc on demand fun. > > While also ensuring the name is sufficiently large for the next decade or so. > > Unfortunately it's part of the uabi. So can't change it without some > risk of userspace breakage. > > The least demanding option is probably to nuke export_head. We need > one bit to replace it, which we can get by either: > - stealing from eg. mode->type, or perhaps mode->private_flags > - nuke private_flags outright and replace it with a bool for this > purpose Looks like getting rid of private_flags is going to be pretty straightforward. I'll post patches for that once this first series lands.
On Thu, 20 Feb 2020 at 14:28, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala > > <ville.syrjala@linux.intel.com> wrote: > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > struct drm_display_mode is extremely fat. Put it on diet. > > > > > > Some stats for the whole series: > > > > > > 64bit sizeof(struct drm_display_mode): > > > 200 -> 136 bytes (-32%) > > > > > > 64bit bloat-o-meter -c drm.ko: > > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) > > > Function old new delta > > > ... > > > Total: Before=189430, After=188779, chg -0.34% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=11667, After=11667, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes 1000 680 -320 > > > edid_est_modes 3400 2312 -1088 > > > edid_cea_modes_193 5400 3672 -1728 > > > drm_dmt_modes 17600 11968 -5632 > > > edid_cea_modes_1 25400 17272 -8128 > > > Total: Before=71239, After=54343, chg -23.72% > > > > > > > > > 64bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547) > > > ... > > > Total: Before=272336, After=254789, chg -6.44% > > > > > > > > > 32bit sizeof(struct drm_display_mode): > > > 184 -> 120 bytes (-34%) > > > > > > 32bit bloat-o-meter -c drm.ko > > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625) > > > Function old new delta > > > ... > > > Total: Before=172359, After=171734, chg -0.36% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=4227, After=4227, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes 920 600 -320 > > > edid_est_modes 3128 2040 -1088 > > > edid_cea_modes_193 4968 3240 -1728 > > > drm_dmt_modes 16192 10560 -5632 > > > edid_cea_modes_1 23368 15240 -8128 > > > Total: Before=59230, After=42334, chg -28.53% > > > > > > 32bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521) > > > ... > > > Total: Before=235816, After=218295, chg -7.43% > > > > > > > > > Some ideas for further reduction: > > > - Convert mode->name to a pointer (saves 24/28 bytes in the > > > struct but would often require a heap alloc for the name (though > > > typical mode name is <10 bytes so still overall win perhaps) > > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only > > > place where we have to preserve the user provided name, elsewhere > > > could pehaps just generate on demand? Not sure how tricky this > > > would get. > > > > The series does some great work, with future work reaching the cache > > line for 64bit. > > Doing much more than that might be an overkill IMHO. > > > > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there, > > avoiding the heap alloc/calc on demand fun. > > While also ensuring the name is sufficiently large for the next decade or so. > > Unfortunately it's part of the uabi. So can't change it without some > risk of userspace breakage. > Right the define is in the uABI. More importantly userspace can provide a drm_mode_modeinfo blob, with a name[32], which we cannot store in the kernel drm_display_mode::name[24]. One might get away with returning -EINVAL if the actual name given by the user is > 24. Since you've found a better way, there's on point in risking it. -Emil
On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > Looks like getting rid of private_flags is going to be pretty > straightforward. I'll post patches for that once this first series > lands. Going all in on crtc state? I suppose migrating away from private_flags could easily start in i915 before that. Seems rather independent. I guess it's __intel_get_crtc_scanline() and: vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)]; mode = &vblank->hwmode; if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP) that gives me the creeps in reviewing all that. There's also [1] adding new uses for private_flags; I think there were issues in getting at the right crtc state on some of those paths, but I forget the exact details. Ideas? BR, Jani. [1] https://patchwork.freedesktop.org/series/69290/
On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote: > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > Looks like getting rid of private_flags is going to be pretty > > straightforward. I'll post patches for that once this first series > > lands. > > Going all in on crtc state? I suppose migrating away from private_flags > could easily start in i915 before that. Seems rather independent. > > I guess it's __intel_get_crtc_scanline() and: > > vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)]; > mode = &vblank->hwmode; > > if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP) > > that gives me the creeps in reviewing all that. > > There's also [1] adding new uses for private_flags; I think there were > issues in getting at the right crtc state on some of those paths, but I > forget the exact details. Ideas? I'm just going to move them to the crtc_state and put a copy into the crtc itself for the vblank code. Pretty much a 1:1 replacement. Saves me from having to think ;)
On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote: > > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > > Looks like getting rid of private_flags is going to be pretty > > > straightforward. I'll post patches for that once this first series > > > lands. > > > > Going all in on crtc state? I suppose migrating away from private_flags > > could easily start in i915 before that. Seems rather independent. > > > > I guess it's __intel_get_crtc_scanline() and: > > > > vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)]; > > mode = &vblank->hwmode; > > > > if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP) > > > > that gives me the creeps in reviewing all that. > > > > There's also [1] adding new uses for private_flags; I think there were > > issues in getting at the right crtc state on some of those paths, but I > > forget the exact details. Ideas? > > I'm just going to move them to the crtc_state and put a copy into the > crtc itself for the vblank code. Pretty much a 1:1 replacement. > Saves me from having to think ;) I've looked through the patches, and didn't spot any place where we couldn't just get at the full crtc state. Might need some crtc->state dereferencing and upcasting and making sure stuff is ordered correctly with enable/disable paths of crtc, but nothing to jump over. Was this maybe predating the switch of the vblank callbacks over from drm_driver to drm_crtc_funcs, and in the former it's indeed not super-obvious that you can just look at the crtc? Anyway, didn't look like it needs private flags at all from a quick scan. -Daniel
On Wed, Feb 19, 2020 at 9:35 PM Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh > drm: Nuke mode->vrefresh I'm sure this is fine. Acked-by: Linus Walleij <linus.walleij@linaro.org> We need one: either clock or refresh settings, so it does make sense to calculate one from the other. So is the reasoning such that we mostly know the clock and the resolutions and then calculate vrefresh? (It makes sense to me in a way.) What I am worried about here is that some of these (especially panels) are probably already out of sync so we need to ascertain that the clock is correct-ish everywhere, so let's be prepared for some regressions. For command-mode DSI panels the vrefresh can become quite weird I think, the vrefresh is different from what you can reverse calculate (I know this from experiments) but I doubt we care much. Yours, Linus Walleij
On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote: > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote: > > > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > > > Looks like getting rid of private_flags is going to be pretty > > > > straightforward. I'll post patches for that once this first series > > > > lands. > > > > > > Going all in on crtc state? I suppose migrating away from private_flags > > > could easily start in i915 before that. Seems rather independent. > > > > > > I guess it's __intel_get_crtc_scanline() and: > > > > > > vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)]; > > > mode = &vblank->hwmode; > > > > > > if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP) > > > > > > that gives me the creeps in reviewing all that. > > > > > > There's also [1] adding new uses for private_flags; I think there were > > > issues in getting at the right crtc state on some of those paths, but I > > > forget the exact details. Ideas? > > > > I'm just going to move them to the crtc_state and put a copy into the > > crtc itself for the vblank code. Pretty much a 1:1 replacement. > > Saves me from having to think ;) > > I've looked through the patches, and didn't spot any place where we > couldn't just get at the full crtc state. Might need some crtc->state > dereferencing and upcasting and making sure stuff is ordered correctly > with enable/disable paths of crtc, but nothing to jump over. swap_state() could easily race with the irq handler. I guess practically unlikely the old crtc state would disappear before the irq handler is done, but still seems somewhat dubious.
On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote: > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote: > > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä > > <ville.syrjala@linux.intel.com> wrote: > > > > > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote: > > > > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > > > > Looks like getting rid of private_flags is going to be pretty > > > > > straightforward. I'll post patches for that once this first series > > > > > lands. > > > > > > > > Going all in on crtc state? I suppose migrating away from private_flags > > > > could easily start in i915 before that. Seems rather independent. > > > > > > > > I guess it's __intel_get_crtc_scanline() and: > > > > > > > > vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)]; > > > > mode = &vblank->hwmode; > > > > > > > > if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP) > > > > > > > > that gives me the creeps in reviewing all that. > > > > > > > > There's also [1] adding new uses for private_flags; I think there were > > > > issues in getting at the right crtc state on some of those paths, but I > > > > forget the exact details. Ideas? > > > > > > I'm just going to move them to the crtc_state and put a copy into the > > > crtc itself for the vblank code. Pretty much a 1:1 replacement. > > > Saves me from having to think ;) > > > > I've looked through the patches, and didn't spot any place where we > > couldn't just get at the full crtc state. Might need some crtc->state > > dereferencing and upcasting and making sure stuff is ordered correctly > > with enable/disable paths of crtc, but nothing to jump over. > > swap_state() could easily race with the irq handler. I guess > practically unlikely the old crtc state would disappear before > the irq handler is done, but still seems somewhat dubious. And I guess the bigger problem is that swap_state() happens way too early. So crtc->state would be pointing to bogus stuff while we're disabling the crtc.
On Fri, Feb 21, 2020 at 06:09:04PM +0200, Ville Syrjälä wrote: > On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote: > > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote: > > > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote: > > > > > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > > > > > Looks like getting rid of private_flags is going to be pretty > > > > > > straightforward. I'll post patches for that once this first series > > > > > > lands. > > > > > > > > > > Going all in on crtc state? I suppose migrating away from private_flags > > > > > could easily start in i915 before that. Seems rather independent. > > > > > > > > > > I guess it's __intel_get_crtc_scanline() and: > > > > > > > > > > vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)]; > > > > > mode = &vblank->hwmode; > > > > > > > > > > if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP) > > > > > > > > > > that gives me the creeps in reviewing all that. > > > > > > > > > > There's also [1] adding new uses for private_flags; I think there were > > > > > issues in getting at the right crtc state on some of those paths, but I > > > > > forget the exact details. Ideas? > > > > > > > > I'm just going to move them to the crtc_state and put a copy into the > > > > crtc itself for the vblank code. Pretty much a 1:1 replacement. > > > > Saves me from having to think ;) > > > > > > I've looked through the patches, and didn't spot any place where we > > > couldn't just get at the full crtc state. Might need some crtc->state > > > dereferencing and upcasting and making sure stuff is ordered correctly > > > with enable/disable paths of crtc, but nothing to jump over. > > > > swap_state() could easily race with the irq handler. I guess > > practically unlikely the old crtc state would disappear before > > the irq handler is done, but still seems somewhat dubious. > > And I guess the bigger problem is that swap_state() happens way too > early. So crtc->state would be pointing to bogus stuff while we're > disabling the crtc. Uh, so we're essentially piggy-packing some random i915 state on top of the hw timing stuff the vblank handler does, and hope that this is race-free enough to not matter? I think the right solution there would be to have a proper spinlock_irqsafe for this stuff that the dsi TE handler needs, and through that make sure that we're actually not going boom. At least it looked like there's also irq handling bits outside of the vblank code, so the vblank locking is not going to safe the day. Or maybe it's really just too late and I should go into w/e :-) -Daniel
On Fri, Feb 21, 2020 at 06:16:57PM +0100, Daniel Vetter wrote: > On Fri, Feb 21, 2020 at 06:09:04PM +0200, Ville Syrjälä wrote: > > On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote: > > > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote: > > > > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä > > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote: > > > > > > On Thu, 20 Feb 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > > > > > > Looks like getting rid of private_flags is going to be pretty > > > > > > > straightforward. I'll post patches for that once this first series > > > > > > > lands. > > > > > > > > > > > > Going all in on crtc state? I suppose migrating away from private_flags > > > > > > could easily start in i915 before that. Seems rather independent. > > > > > > > > > > > > I guess it's __intel_get_crtc_scanline() and: > > > > > > > > > > > > vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)]; > > > > > > mode = &vblank->hwmode; > > > > > > > > > > > > if (mode->private_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP) > > > > > > > > > > > > that gives me the creeps in reviewing all that. > > > > > > > > > > > > There's also [1] adding new uses for private_flags; I think there were > > > > > > issues in getting at the right crtc state on some of those paths, but I > > > > > > forget the exact details. Ideas? > > > > > > > > > > I'm just going to move them to the crtc_state and put a copy into the > > > > > crtc itself for the vblank code. Pretty much a 1:1 replacement. > > > > > Saves me from having to think ;) > > > > > > > > I've looked through the patches, and didn't spot any place where we > > > > couldn't just get at the full crtc state. Might need some crtc->state > > > > dereferencing and upcasting and making sure stuff is ordered correctly > > > > with enable/disable paths of crtc, but nothing to jump over. > > > > > > swap_state() could easily race with the irq handler. I guess > > > practically unlikely the old crtc state would disappear before > > > the irq handler is done, but still seems somewhat dubious. > > > > And I guess the bigger problem is that swap_state() happens way too > > early. So crtc->state would be pointing to bogus stuff while we're > > disabling the crtc. > > Uh, so we're essentially piggy-packing some random i915 state on top of > the hw timing stuff the vblank handler does, and hope that this is > race-free enough to not matter? > > I think the right solution there would be to have a proper > spinlock_irqsafe for this stuff that the dsi TE handler needs, and through > that make sure that we're actually not going boom. At least it looked like > there's also irq handling bits outside of the vblank code, so the vblank > locking is not going to safe the day. I haven't actually looked at the DSI TE stuff so far, so no idea what's going on there.
From: Ville Syrjälä <ville.syrjala@linux.intel.com> struct drm_display_mode is extremely fat. Put it on diet. Some stats for the whole series: 64bit sizeof(struct drm_display_mode): 200 -> 136 bytes (-32%) 64bit bloat-o-meter -c drm.ko: add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) Function old new delta ... Total: Before=189430, After=188779, chg -0.34% add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Data old new delta Total: Before=11667, After=11667, chg +0.00% add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) RO Data old new delta edid_4k_modes 1000 680 -320 edid_est_modes 3400 2312 -1088 edid_cea_modes_193 5400 3672 -1728 drm_dmt_modes 17600 11968 -5632 edid_cea_modes_1 25400 17272 -8128 Total: Before=71239, After=54343, chg -23.72% 64bit bloat-o-meter drm.ko: add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547) ... Total: Before=272336, After=254789, chg -6.44% 32bit sizeof(struct drm_display_mode): 184 -> 120 bytes (-34%) 32bit bloat-o-meter -c drm.ko add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625) Function old new delta ... Total: Before=172359, After=171734, chg -0.36% add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Data old new delta Total: Before=4227, After=4227, chg +0.00% add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) RO Data old new delta edid_4k_modes 920 600 -320 edid_est_modes 3128 2040 -1088 edid_cea_modes_193 4968 3240 -1728 drm_dmt_modes 16192 10560 -5632 edid_cea_modes_1 23368 15240 -8128 Total: Before=59230, After=42334, chg -28.53% 32bit bloat-o-meter drm.ko: add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521) ... Total: Before=235816, After=218295, chg -7.43% Some ideas for further reduction: - Convert mode->name to a pointer (saves 24/28 bytes in the struct but would often require a heap alloc for the name (though typical mode name is <10 bytes so still overall win perhaps) - Get rid of mode->name entirely? I guess setcrtc & co. is the only place where we have to preserve the user provided name, elsewhere could pehaps just generate on demand? Not sure how tricky this would get. - Eliminate the second list head somehow? Pie in the sky idea: - Eliminate the normal vs. crtc_ dual timings where not needed. Ie. Just use two structs if necessary instead of packing both to the same struct. Can't imagine this being an easy conversion. Entire series available here: git://github.com/vsyrjala/linux.git drm_mode_diet_4 Ville Syrjälä (12): drm: Nuke mode->hsync drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh drm/i915: Introduce some local intel_dp variables drm: Nuke mode->vrefresh drm/msm/dpu: Stop copying around mode->private_flags drm: Shrink {width,height}_mm to u16 drm: Shrink mode->type to u8 drm: Make mode->flags u32 drm: Shrink drm_display_mode timings drm: Flatten drm_mode_vrefresh() drm: Shrink mode->private_flags drm: pahole struct drm_display_mode drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/drm_client_modeset.c | 2 +- drivers/gpu/drm/drm_edid.c | 328 +++++++++--------- drivers/gpu/drm/drm_modes.c | 54 +-- drivers/gpu/drm/drm_probe_helper.c | 3 - drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +- drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- drivers/gpu/drm/i2c/ch7006_mode.c | 1 - drivers/gpu/drm/i915/display/intel_display.c | 2 - .../drm/i915/display/intel_display_debugfs.c | 4 +- drivers/gpu/drm/i915/display/intel_dp.c | 24 +- drivers/gpu/drm/i915/display/intel_tv.c | 3 - drivers/gpu/drm/mcde/mcde_dsi.c | 6 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 +- drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +- drivers/gpu/drm/panel/panel-arm-versatile.c | 4 - drivers/gpu/drm/panel/panel-boe-himax8279d.c | 3 +- .../gpu/drm/panel/panel-boe-tv101wum-nl6.c | 6 +- .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 3 +- .../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +- drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 7 - drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 +- drivers/gpu/drm/panel/panel-innolux-p079zca.c | 4 +- .../gpu/drm/panel/panel-jdi-lt070me05000.c | 3 +- .../drm/panel/panel-kingdisplay-kd097d04.c | 3 +- .../drm/panel/panel-leadtek-ltk500hd1829.c | 3 +- drivers/gpu/drm/panel/panel-lg-lb035q02.c | 1 - drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 +- drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 1 - drivers/gpu/drm/panel/panel-novatek-nt39016.c | 1 - .../drm/panel/panel-olimex-lcd-olinuxino.c | 1 - .../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 +- .../drm/panel/panel-osd-osd101t2587-53ts.c | 3 +- .../drm/panel/panel-panasonic-vvx10f034n00.c | 3 +- .../drm/panel/panel-raspberrypi-touchscreen.c | 4 +- drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 +- drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 +- .../drm/panel/panel-rocktech-jh057n00900.c | 5 +- drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 1 - drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 6 - drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 4 +- .../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 +- drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 3 +- .../panel/panel-samsung-s6e88a0-ams452ef01.c | 1 - drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 3 +- .../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 3 +- .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 1 - .../gpu/drm/panel/panel-sharp-ls043t1le01.c | 3 +- drivers/gpu/drm/panel/panel-simple.c | 85 +---- drivers/gpu/drm/panel/panel-sitronix-st7701.c | 2 +- .../gpu/drm/panel/panel-sitronix-st7789v.c | 3 +- drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 - drivers/gpu/drm/panel/panel-sony-acx565akm.c | 1 - drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 1 - drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 1 - drivers/gpu/drm/panel/panel-tpo-tpg110.c | 5 - drivers/gpu/drm/panel/panel-truly-nt35597.c | 1 - .../gpu/drm/panel/panel-xinpeng-xpp055c272.c | 3 +- drivers/gpu/drm/sti/sti_hda.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 - include/drm/drm_modes.h | 211 +++++------ 66 files changed, 341 insertions(+), 568 deletions(-)