columbarius has quit [Read error: Connection reset by peer]
columbarius has joined #dri-devel
bolson_ has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
nucfreq has quit [Quit: nucfreq]
columbarius has joined #dri-devel
co1umbarius has quit [Read error: No route to host]
aravind has joined #dri-devel
fab has quit [Quit: fab]
nucfreq has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
fab has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
fab has quit []
fab has joined #dri-devel
iyes has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Read error: Connection reset by peer]
jsa has quit [Ping timeout: 480 seconds]
<robclark>
sima, I'm wondering how the wq based drm sched doesn't cause fence signaling path issues.. ie. isn't it possible for the thread that work gets run on to be blocked in reclaim for some unrelated work?
co1umbarius has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
jsa has joined #dri-devel
fab has quit [Quit: fab]
vliaskov has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
lemonzest has joined #dri-devel
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
columbarius has joined #dri-devel
kzd has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
ced117 has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
bolson has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
kasper93 has joined #dri-devel
columbarius has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Ping timeout: 480 seconds]
<sima>
robclark, it's supposed to be multi-threaded enough
simon-perretta-img has joined #dri-devel
<sima>
but yeah the driver can block itself, or it's wq
<robclark>
sima: but, I think we want something with dedicated thread(s), not something that shares threads with other parts of the kernel
mbrost has joined #dri-devel
<sima>
robclark, wq maintainer consensus is a very strong "nope" because everyone creating their dedicated threads causes massive overhead
<sima>
so now the wq subsystem folds them all together and forks new ones as needed
<sima>
or at least that's the promise
Celmor[m] has joined #dri-devel
<robclark>
right, but forking a new one requires allocating memory, so we can't rely on that
Wallbraker has joined #dri-devel
AlaaEmad[m] has joined #dri-devel
ajhalaney[m] has joined #dri-devel
Alex[m]123456789101112 has joined #dri-devel
<robclark>
idk if we could use kthread_work somehow.. but current thing seems broken
<sima>
robclark, hm, not sure anyone thought about that one before, since it's rather common to do a lot of stuff with wq ..
arisu has joined #dri-devel
AndreyKonovalov[m] has joined #dri-devel
Andy[m] has joined #dri-devel
<sima>
robclark, tdr was also a work item, so we had that issue already beforehand
aradhya7[m] has joined #dri-devel
Pierce[m] has joined #dri-devel
<sima>
maybe there's some "this is needed for reclaim" flag for creating the wq?
aura[m] has joined #dri-devel
bubblethink[m] has joined #dri-devel
bylaws1 has joined #dri-devel
<robclark>
idk, there is a highpriority flag, but idk if that will really help
chema has joined #dri-devel
<sima>
robclark, the much bigger issue is that I think still all drm/sched drivers allocate in their ->run callback, so that's much worse
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
<robclark>
hmm, I don't
<sima>
and I've kinda not gotten around to that since years ...
Coelacanthus[m]1 has joined #dri-devel
<sima>
well at least back when I checked last time around they were all splatting nicely
Eighth_Doctor has joined #dri-devel
<robclark>
I'm not quite to the point of enabling drm/sched fence signaling annotations, but that should be the goal
QiuWenbo[m] has joined #dri-devel
<sima>
yeah
<robclark>
yeah, there were some indirect issues with runpm/interconnect/etc
cwfitzgerald[m] has joined #dri-devel
<robclark>
some of my fixes for that have landed
dafna33[m] has joined #dri-devel
<sima>
just kinda thinking that we should get to that first before pondering whether wq itself is good enough ...
daissi has joined #dri-devel
<sima>
yeah I remember all the rpm discussion, good fun
<robclark>
most of them weren't _real_ issues, but just same lock tangled up in runtime vs startup allocations
daniliberman[m] has joined #dri-devel
dcbaker has joined #dri-devel
<robclark>
whereas the wq issue is I think a legit deadlock that we can hit
DemiMarie has joined #dri-devel
devarsht[m] has joined #dri-devel
devnull[m] has joined #dri-devel
Anson[m] has joined #dri-devel
<sima>
robclark, yeah ... otoh I'm hungry and it's time to prep some food :-)
<sima>
ttyl
dhirschfeld2[m] has joined #dri-devel
DrNick has joined #dri-devel
doras has joined #dri-devel
<robclark>
(also, gabertron was seeing some jank issues traced back to the wq migration... which is kinda what got me wondering if using a wq is actually fundamentally sound)
doraskayo has joined #dri-devel
danylo1 has joined #dri-devel
EricCurtin[m] has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
eballetbo has joined #dri-devel
enunes[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
exp80[m] has joined #dri-devel
Lucretia has quit []
fililip[m] has joined #dri-devel
fkassabri[m] has joined #dri-devel
FL4SHK[m] has joined #dri-devel
FloGrauper[m] has joined #dri-devel
gallo[m] has joined #dri-devel
gdevi has joined #dri-devel
gegoxaren[m] has joined #dri-devel
<sima>
robclark, yeah maybe we need to ask really strongly for dedicated thread again
general_j[m] has joined #dri-devel
simon-perretta-img has quit [Remote host closed the connection]
gnustomp[m] has joined #dri-devel
go4godvin has joined #dri-devel
Armote[m] has joined #dri-devel
<sima>
like I think it can still be on-demand allocated, but it must not be freed as long as something is queued up
MotiH[m] has joined #dri-devel
halfline[m] has joined #dri-devel
simon-perretta-img has joined #dri-devel
Harvey[m] has joined #dri-devel
<robclark>
maybe we can ask for a thread that is lockdep annotated for reclaim
<sima>
otoh that's only good enough for classic end-of-batch dma_fence jobs and not the preempt variant and all the other guc stuff xe needs to push through
hax0kartik[m] has joined #dri-devel
Hazematman has joined #dri-devel
hch12907 has joined #dri-devel
<sima>
robclark, there's enough for that already, if you add dma_fence annotations
<robclark>
ofc then we have to finish fixing all the fence signaling annotation issues, but it would be a good way of anyone using the thread to do allocations
healfdanex[m] has joined #dri-devel
<sima>
the issue is what happens for on-demand thread allocation ...
heftig has joined #dri-devel
Hi-Angel has joined #dri-devel
<sima>
since that's not covered by the current wq annotations, so we can't toss in our own annotations (or just do stuff like fs_reclaim annotations directly)
<robclark>
yeah, we'd have to have threads already existing.. but one or small # might be sufficient
zzoon[m] has joined #dri-devel
ids1024[m] has joined #dri-devel
isinyaaa[m] has joined #dri-devel
jasuarez has joined #dri-devel
jenatali has joined #dri-devel
joantolo[m] has joined #dri-devel
JosExpsito[m] has joined #dri-devel
jtatz[m] has joined #dri-devel
K0bin[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
madhavpcm has joined #dri-devel
kerel has joined #dri-devel
kelbaz[m] has joined #dri-devel
koki23[m] has joined #dri-devel
yyds has quit [Remote host closed the connection]
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
LaughingMan[m] has joined #dri-devel
m00nlit[m] has joined #dri-devel
<sima>
robclark, I think (but very unsure) that just one emergency thread per system, that does nothing else than process dma_fence work item, should be enough
mairacanal[m] has joined #dri-devel
MarkCollins[m] has joined #dri-devel
columbarius has joined #dri-devel
marmarek[m] has joined #dri-devel
martix778777[m] has joined #dri-devel
masush5[m] has joined #dri-devel
matrix638[m] has joined #dri-devel
<robclark>
I think so
MayeulC has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard1 has joined #dri-devel
<robclark>
if wq maintainer don't want to accept a drm specific WQ flag, we could pitch it as WQ_RECLAIM_DISALLOWED and have the annotation at the wq level
msizanoen[m] has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
nick1343[m] has joined #dri-devel
nicofee[m] has joined #dri-devel
nielsdg has joined #dri-devel
nyorain[m] has joined #dri-devel
ofirbitt[m] has joined #dri-devel
ohadsharabi[m] has joined #dri-devel
onox[m] has joined #dri-devel
orowith2os[m] has joined #dri-devel
pac85[m] has joined #dri-devel
pankart[m] has joined #dri-devel
pedrohlc[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
Guest2769 has joined #dri-devel
pushqrdx[m] has joined #dri-devel
q4a has joined #dri-devel
Quinten[m] has joined #dri-devel
valida-69[m] has joined #dri-devel
raambm[m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
ram15[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
samueldr has joined #dri-devel
dabrain34[m] has joined #dri-devel
siddh has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
SintayewGashaw[m] has joined #dri-devel
sergi has joined #dri-devel
Sumera[m] has joined #dri-devel
swick[m] has joined #dri-devel
sythemeta847[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tak2hu[m] has joined #dri-devel
talcohen[m] has joined #dri-devel
Targetball[m] has joined #dri-devel
tayloralgo1[m] has joined #dri-devel
terribletea[m] has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
tomeu has joined #dri-devel
<tursulin>
robclark, sima: kthread_work is what I mentioned in the early days of drm sched wq rework
Tooniis[m] has joined #dri-devel
kos_tom has joined #dri-devel
treeq[m] has joined #dri-devel
ttayar[m] has joined #dri-devel
tuxayo has joined #dri-devel
Lucretia has joined #dri-devel
<tursulin>
memory is hazy but I thought it would be less latency regression and still be able to allocate one or many as per driver needs
simon-perretta-img has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
columbarius has quit [Remote host closed the connection]
columbarius has joined #dri-devel
<robclark>
tursulin: if we can make kthread_work work, I think that would be the best option
simon-perretta-img has quit [Read error: No route to host]
<robclark>
tursulin: re: fdinfo sysfs, I think the best excuse I can think of for wanting text over binary is scripting
<sima>
tursulin, uh I think that needs an ack from gregkh or we really can't just land it
simon-perretta-img has joined #dri-devel
<sima>
the entire idea I mean, irrespective of the binary vs ascii part
heat has joined #dri-devel
<robclark>
hmm, gregkh wasn't cc'd... that should probably be corrected when next version is sent
<robclark>
but we defn need something like this
<sima>
robclark, yeah but maybe in procfs instead?
<sima>
like at least to me sysfs feels very wrong
<robclark>
hmm, perhaps.. it is kinda proc related
kts_ has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
<tursulin>
or, wait for it, drmfs of some sort
<robclark>
idk about drmfs... sounds a bit like encouraging drivers to create too much uabi ;-)
<robclark>
mbrost, tursulin: so I'm wondering, would it work for wq alternative to just have driver pass in a kthread_worker? Then drivers could choose one kthread_worker per scheduler (to match old behavior) or a fixed #? Like I guess guc has a fixed # of priority levels, one kthread_worker per priority level seems like it should work?
<daniels>
alarumbe: ^
<tursulin>
robclark: haha maybe on drmfs.. could be handy for per client stuff like debug streams, profiling, who knows
<tursulin>
kthread_work I think should be possible as almost a drop in replacement. Long time since those disuccsions so maybe I am forgetting something but don't think so
kts has joined #dri-devel
<alarumbe>
hi, I was preparing a v3 of the drm clients patch series, but this time around I'll be using a specific ioctl
<robclark>
hmm, I think I like the procfs (or sysfs) better than ioctl
columbarius has quit [Remote host closed the connection]
<alarumbe>
I realised sysfs is not really the way to go, because the number of PIDs could potentially extend over the size of a single page, and binary attributes don't really work either, because they're meant for binary date that doesn't change between read() calls
columbarius has joined #dri-devel
<alarumbe>
I thought of using the private field in the file pointer to store all the PIDs when calling show() with offset=0, but then we wouldn't know when to free it because we've no control over the release() method for the file
<alarumbe>
I've a working implementation using an ioctl that somehow feeels more natural than all the ugly hacks I thought of on top of the sysfs attribute interface
<mbrost>
robclark: I missed the beginning of this conversation, what is the issue with a wq?
<alarumbe>
I'd rather still keep the ioctl output binary because there's already a debugfs file that gives the list of clients, and I thought this new thing was meant to service the needs of UM profilers
coldfeet has quit [Remote host closed the connection]
<robclark>
mbrost: wq shares thread w/ other drivers, so no guarantee that thread isn't blocked on reclaim
columbarius has quit [Ping timeout: 480 seconds]
<mbrost>
even a dedicated ordered work queue?
vliaskov has quit [Ping timeout: 480 seconds]
<mbrost>
e.g. one from alloc_ordered_workqueue
<robclark>
I believe so.. but I haven't dug completely thru the wq code
<mbrost>
that doesn't seem right but if it is, then yea that is a problem
columbarius has joined #dri-devel
<robclark>
alarumbe: tbh I'd be fine if we define the procfs as just listing the first N clients.. at some point a viz tool will have a hard time showing an unbounded # of processes
<alarumbe>
I thought about that, 'why would anyone need to list more than 1024 DRM clients simultaneously on an ncurses utility'
<mbrost>
did this pop up in 6.9? We had some issues hitting deadlocks in Xe due to our workqueue usage / work queue changes is 6.9
<alarumbe>
but then after trying to cram as many pids as possible into a single page, I thought maybe DRM ioctl would do a better job