Re: freezing system for several second on high I/O [kernel 4.15]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux