| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | ChanServ sets mode: +o mchehab` | [01:03] |
| ............ (idle for 56mn) | ||
| ChanServ sets mode: +o mchehab` | [01:59] | |
| ...................... (idle for 1h48mn) | ||
| ChanServ sets mode: +o mchehab` | [03:47] | |
| ...................................................................................................................................... (idle for 11h8mn) | ||
| marc|gonzalez | mchehab: there are occurrences of kmalloc(1, GFP_KERNEL); and kmalloc(2, GFP_KERNEL); just for the lifetime of a single function. That seems excessive... | [14:55] |
| mchehab | agreed. the code probably need some rework
without knowing where it happens, I bet those are due to DMA buffers that can't be at stack the right fix would be to have a temp buffer allocated together with the dev-specific struct | [14:58] |
| marc|gonzalez | mchehab: hehehe, I didn't dare say where, because it's one of the media maintainers ;-) | [14:59] |
| mchehab | and having a mutex to avoid concurrency
the code you're likely mentioning is due to a bug fix after a Kernel change that caused a regression on almost every USB media driver the quick/safe fix were to change stack alloc to kmalloc | [14:59] |
| marc|gonzalez | I see, but allocating 1 or 2 bytes on the heap sounds very wasteful (in memory and CPU), and it's unlikely to be a problem on the stack | [15:11] |
| mchehab | stack doesn't do DMA transfers
any URB object should be allocated with kmalloc | [15:11] |
| marc|gonzalez | mchehab: haaaaa | [15:12] |
| mchehab | what most drivers do is that a temp buff is allocated at their struct driver_dev
so, a single allocation but that requires a mutex | [15:12] |
| marc|gonzalez | I think I see the issue now
Thanks for taking the time to explain | [15:13] |
| mchehab | specially if the same buffer is used also for polling events (for CI and IR) | [15:13] |
| marc|gonzalez | mchehab: in dvb_pll_attach() it is an URB object? | [15:14] |
| mchehab | on several drivers, I2C transfers happen via URB
dvb_pll can be used for I2C transfers | [15:14] |
| marc|gonzalez | wow, so much complexity, it's humbling... | [15:15] |
| mchehab | also, tuning a device is an operation that doesn't occur too often - the memory pressure of doing a kalloc/kfree inside it is minimal | [15:15] |
| marc|gonzalez | I see, I was thinking about the maintenance burden of the error-handling | [15:16] |
| mchehab | the maintainance burden of breaking random devices due to DMA on stack is a lot worse | [15:16] |
| marc|gonzalez | smirk
I have a random crash in my system that comes several seconds after a dvbv5-scan, mchehab any idea what could this be? | [15:17] |
| mchehab | no, sorry. my crystal ball is broken :-p | [15:19] |
| marc|gonzalez | smirk :-)
Do you know that there is one girl named Kristal Ball? weird parents... | [15:20] |
| mchehab | or maybe it is an artistic name she choose | [15:21] |
| b-rad | you wany mysterious names go to africa where they just choose two arbitrary words they like
i've met lawyer doctor, patient person, etc | [15:22] |
| mchehab | I suspect that most names are like that... | [15:24] |
| b-rad | yup, you choose what you like | [15:24] |
| mchehab | except that the origin of a name usually comes from an old language | [15:24] |
| marc|gonzalez | "Ball was born to Edward and Rose Marie Ball, a physicist and a teacher, respectively. The name Krystal came from her father, a physicist who did his dissertation on crystals." | [15:25] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |