On 15 February 2018 at 10:44, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> I've already explained that we can't annotate these memory
> allocations to turn off the false positives because that will also
> turning off all detection of real deadlock conditions. Lockdep has
> many, many limitations, and this happens to be one of them.
>
> FWIW, is there any specific reason you running lockdep on your
> desktop system?
Because I wanna make open source better (help fixing all freezing)
>
> I think I've already explained that, too. The graphics subsystem -
> which is responsible for updating the cursor - requires memory
> allocation. The machine is running low on memory, so it runs memory
> reclaim, which recurses back into the filesystem and blocks waiting
> for IO to be completed (either writing dirty data pages or flushing
> dirty metadata) so it can free memory.
Which means machine is running low on memory?
How many memory needed?
$ free -h
total used free shared buff/cache available
Mem: 30G 17G 2,1G 1,4G 10G 12G
Swap: 59G 0B 59G
As can we see machine have 12G available memory. Is this means low memory?
> IOWs, your problems all stem from long IO latencies caused by the
> overloaded storage subsystem - they are propagate to all
> aspects of the OS via direct memory reclaim blocking on IO....
I'm surprised that no QOS analog for disk I/O.
This is reminiscent of the situation in past where a torrent client
clogs the entire channel on the cheap router and it causes problems
with opening web pages. In nowadays it never happens with modern
routers even with overloaded network channel are possible video calls
.
In 2018 my personaly expectation that user can run any set of
applications on computer and this never shoudn't harm system.
--
Best Regards,
Mike Gavrilov.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
