On 12/11/2013 12:35 PM, Lauri Kasanen wrote: > On Wed, 11 Dec 2013 12:04:05 +0900 > Michel D?nzer <michel at daenzer.net> wrote: > >>> Of all the worries that exist, this is a non-issue. Userspace can >>> simply queue a lot of draw calls that take 1 second each through the >>> normal command submission methods, why would it need to tweak some >>> obscure number to cause some eviction? >> That's not what I'm concerned about. >> >> Consider e.g. a multiseat environment: Some users could patch their >> userspace drivers such that their buffers are more likely to stay in >> VRAM than those of other users. >> >> I agree it's not a huge issue, I'm just saying we should try to make the >> score calculation as much as possible based on the actual usage of the >> buffers instead of on meta data provided by userspace. > We don't have that in the kernel. Only userspace has the accurate stats > on usage. If we instead modified userspace to pass these stats, it > would have the exact same issue of "what if somebody passes false data"? > > Maarten: >> Well, the easiest solution is to make the score only count as penalty, >> and set buffers that don't have the meta-data to maximum score. This >> preserves current behavior for clients that aren't score aware. > No, this would be the exact opposite: it would pin the old-userspace > buffers, at the cost of possibly not letting proper-scored buffers in > VRAM. > > Thomas: >> I agree with Michel that some mechanism needs to be in place to stop >> user-space clients from effectively pinning buffers by giving them a certain >> > score. > I think the kernel just has to trust userspace on this. I can't think > of any way of not involving userspace, so if somebody really wants to > hack mesa to gain some fps advantage on a multiseat system, let them ;) > > Basically, they already can hack mesa to pass invalid buffers to cause > a hang/crash the kernel. So we already trust userspace more than this > new functionality would.
Yes, but these are two different things. Letting user-space pin buffers by design is building in a software DOS in the kernel. I don't think even Microsoft is allowing this, and AFAICT we've avoided that since the very dawn of kernel buffer management. Not having a perfect command stream parser or proper GPU hang recovery mechanism is something else, and something we wish to have but don't at the moment. Allowing a new type of DOS just because we have other flaws isn't moving things forward, but i guess in the end it's your choice. Thanks, Thomas
