net: stmmac: Use readl_poll_timeout - net-next.git

diff options

author	LABBE Corentin <clabbe.montjoie@gmail.com>	2017-02-08 09:31:13 +0100
committer	David S. Miller <davem@davemloft.net>	2017-02-08 15:11:25 -0500
commit	8a70aeca80c2425b60ff821140b5b5c141e28ba1 (patch)
tree	094a2ccf44fa5d2e331072b04e911814d3278227 /tools/lguest/extract
parent	a5f48adc316aa21944c19019583fb9933af01b9a (diff)

net: stmmac: Use readl_poll_timeout

The dwmac_dma_reset function use an open coded of readl_poll_timeout(). Replace the open coded handling with the proper function. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>

Diffstat (limited to 'tools/lguest/extract')

0 files changed, 0 insertions, 0 deletions

: tunables 0 0 0 : slabdata 757086 757086 0 kmalloc-128 42754240 42754240 128 32 1 : tunables 0 0 0 : slabdata 1336070 1336070 0 The huge numbers above come from insane number of async_work-s allocated and queued by btrfs_wq_run_delayed_node. The problem is caused by btrfs_wq_run_delayed_node() queuing more and more works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The worker func (btrfs_async_run_delayed_root) processes at least BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery works as expected while the list is almost empty. As soon as it is getting bigger, worker func starts to process more than one item at a time, it takes longer, and the chances to have async_works queued more than needed is getting higher. The problem above is worsened by another flaw of delayed-inode implementation: if async_work was queued in a throttling branch (number of items >= BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that the func occupies CPU infinitely (up to 30sec in my experiments): while the func is trying to drain the list, the user activity may add more and more items to the list. The patch fixes both problems in straightforward way: refuse queuing too many works in btrfs_wq_run_delayed_node and bail out of worker func if at least BTRFS_DELAYED_WRITEBACK items are processed. Changed in v2: remove support of thresh == NO_THRESHOLD. Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com> Signed-off-by: Chris Mason <clm@fb.com> Cc: stable@vger.kernel.org # v3.15+

Diffstat (limited to 'tools/perf/util')


context:
space:
mode: