| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before putting a page back in the pool be sure that it doesn't have
any additional references that would be a signal that somebody else
is looking at the page and that it would be a bad idea to keep it
around and run the risk of accidentally handing it to a different
process.
Change-Id: Ic0dedbad0cf2ffb34b76ad23e393c5a911114b82
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Kamal Agrawal <quic_kamaagra@quicinc.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
do_shrink_slab() scans each shrinker in batches of at most
batch_size (128) pages at a time until total_scan pages are
scanned or until shrinker returns SHRINK_STOP. Under heavy
memory pressure total_scan can be large (in thousands) and
kgsl_pool_shrink_scan_objects() ends up returning 0 after
all pages that were reclaimable are reclaimed. This results in
multiple calls to kgsl_pool_shrink_scan_objects() that do not
reclaim any memory. To prevent this kgsl_pool_shrink_scan_objects()
is modified to return SHRINK_STOP as soon as no more memory can
be reclaimed.
Bug: 69931996
Test: tested using alloc-stress with additional traces
Change-Id: Ia48fc2c0d888c54ec9642c0b0962a70ca3cb4c5e
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 90d6246fca5f288606551c5d02af920bfeb05b9b.
To address the launch latency issue seen because of increase in
memory allocation time.
Change-Id: I147ca8607337541b7a29056b4bd1b46aa374c6e3
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
| |
In case memory pools are supported return the page size as
supported only if corresponding memory pool is available.
This will increase the usage of memory pool and will reduce the
overall allocation time.
Change-Id: Iea84a4259b38fe9cb546419dfcbaf0a9666e7ca9
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Doing a memset to zero while adding a page to pool is not
efficient as the page added to the pool can be returned to
system in case shrinker kicks in. In this scenario, time spent
in zeroing the page is a waste.
Instead of zeroing the page while adding it to pool zero the
page when it is taken from the pool. This helps in reducing
the time taken to free big chunk of memory. Also, allocation
time shouldn't be a problem as zeroing of page anyways happens
during allocation in case it is allocated from system.
Change-Id: I41ab2cb88fb4fd9854d2cc9a45bb60fc7013286a
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In current code, if a request comes to allocate a page of a size
for which pool is not supported EAGAIN is returned with a page
size of PAGE_SIZE << --order. This is not efficient as it results
in multiple retries in case pool of size = PAGE_SIZE << --order is
also not supported.
Instead of retrying with lower order page in a sequential manner
this change directly returns the page size of the pool that is
supported.
Change-Id: Ib82ae5be7e4109fdc0a3d72bcbcd4b47cfb2e266
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
Try to allocate pages from lower order mempools incase
if requested memory size order does not match with the
available mempools.
Change-Id: Idbe4dae3b8bb2a3165199b6959ad4fbf36559964
Signed-off-by: Rajesh Kemisetti <rajeshk@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
Allow driver to get pages from the system incase mempool configuration
is not defined from the device tree. This will fix kgsl driver probe
failure for without gpu mempool configuration devices.
Change-Id: I3142a5d2e13ed40f643c91594fd868c37620ce54
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
| |
Add driver support to configure mempools from the device tree.
This will enable mempools to configure per device specific and
reduces the high kgsl memory usage based on configuration.
CRs-Fixed: 1064046
Change-Id: I0a7e36b7e1fef9d42a4c0fe33d69a4debf15af2f
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the low memory killer runs early in execution, it could free
several reserved pages and for pools which are not allowed to
allocate new pages, those pages are gone forever. Change the
shrinker to not free the reserved pages from pools which are not
allowed to allocate new pages.
Crs-Fixed: 1052430
Change-Id: I65631628a3043fe7c2f74d41bb116fe1b6255873
Signed-off-by: Shrenuj Bansal <shrenujb@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done to improve the kgsl vmfault routine. Currently,
it traverses the sglist to find the faulted page, which takes
linear time. By having an array of all the page pointers,
this operation will be completed in constant time.
Also, allocate sgt only for mapping this memory to the GPU.
Since this optimization is not needed for secure/global or
imported memory, we will not keep this array but keep
the sgt instead.
CRs-Fixed: 1006012
Change-Id: I221fce9082da0bdd59842455221b896a33a6ce42
Signed-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a free page is not found in a particular pool, we
fall back to lower order pools. While doing so make
sure we dont do that when already in zero order pool.
For zero order(pool_idx = 0) pool, (pool_idx-1) value
becomes -1 that is invalid and compiler throws the error
that array subscript is below bounds.
This problem is exposed when we enable kernel config option
"CONFIG_ALLOC_BUFFERS_IN_4K_CHUNKS" which will force only
zero order pool and hence the index value calculation to -1.
Change-Id: I81e8a1e79cd974b7a13a9d23cb3d809464b6dcda
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change includes the below:
- Add 1M and 8k pools and structure the allocator to use all pools
from the largest page to the smallest
- Reserve a set number of pages for each of these pools at init time
- When allocating, use the reserved pools and then fall back to
allocating from system memory using only 8k and 4k pages
- Remove maximums on the pool sizes
- Zero the memory when we create the pool initially and add pages
back to the pool on free
CRs-Fixed: 995735
Change-Id: I9440bad62d3e13b434902f167c9d23467b1c4235
Signed-off-by: Shrenuj Bansal <shrenujb@codeaurora.org>
|
|
|
Use a mempool to reduce the allocation time. When memory allocated
from pages is freed, put it in a page pool. At allocation time, try
to allocate from the page pool before getting pages from the system.
Make sure that the pool does not grow too big by enforcing a
maximum limit.
Change-Id: Icac7fb4355ee1fd07e7127ea5c2721665e279272
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
|
