search for: rfcv2

Compaction calls interfaces of driver page migration instead of calling balloon migration directly. Signed-off-by: Gioh Kim <gioh.kim at lge.com> --- drivers/virtio/virtio_balloon.c | 1 + mm/compaction.c | 9 +++++---- mm/migrate.c | 21 ++++++++++++--------- 3 files changed, 18 insertions(+), 13 deletions(-) diff --git

Add framework to register callback functions and check pages migratable. There are some modes of page isolation so that isolate interface has an arguments of page address and isolation mode. Signed-off-by: Gioh Kim <gioh.kim at lge.com> --- include/linux/compaction.h | 11 +++++++++++ include/linux/fs.h | 2 ++ include/linux/page-flags.h | 19 +++++++++++++++++++

Apply driver page migration into balloon driver. Signed-off-by: Gioh Kim <gioh.kim at lge.com> --- drivers/virtio/virtio_balloon.c | 3 +++ fs/proc/page.c | 3 +++ include/linux/balloon_compaction.h | 33 +++++++++++++++++++++------------ include/uapi/linux/kernel-page-flags.h | 2 +- mm/balloon_compaction.c | 19 +++++++++++++++++-- 5

On 23.05.2018 20:24, David Hildenbrand wrote: > This is the Linux driver side of virtio-mem. Compared to the QEMU side, > it is in a pretty complete and clean state. > > virtio-mem is a paravirtualized mechanism of adding/removing memory to/from > a VM. We can do this on a 4MB granularity right now. In Linux, all > memory is added to the ZONE_NORMAL, so unplugging cannot be

On Fri, Jun 26, 2015 at 12:58 PM, Gioh Kim <gioh.kim at lge.com> wrote: > Compaction calls interfaces of driver page migration > instead of calling balloon migration directly. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 1 + > mm/compaction.c | 9 +++++---- > mm/migrate.c | 21

On Fri, Jun 26, 2015 at 12:58 PM, Gioh Kim <gioh.kim at lge.com> wrote: > Compaction calls interfaces of driver page migration > instead of calling balloon migration directly. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 1 + > mm/compaction.c | 9 +++++---- > mm/migrate.c | 21

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. If the device requests the feature VIRTIO_CONSOLE_F_DMA_MEM, but the architecture don't support DMA the driver's probe function will fail. This is needed for using

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. If the device requests the feature VIRTIO_CONSOLE_F_DMA_MEM, but the architecture don't support DMA the driver's probe function will fail. This is needed for using

Viswanath Puttagunta wrote: > Can we please have review on RFCv2? We have quite a few optimizations > (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward > etc) that are in my pipeline that depend on this patch series being > accepted. So, trying to make progress on this... On an armv7l board running Ubuntu, you've broken the buil...

...t; > 2. Provide scaling as argument to ne10_fft_c2c_1d_float32_neon() and > remove need for one buffer on stack (ALLOC(tempin, st->nfft, > ne10_fft_cpx_float32_t);). We will still need cfg->buffer. So, peak stack usage > goes up by ~3.8K instead of ~7.5K. > > Hope to get the RFCv2 by end of next week. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store o...

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

Sorry for typo.. from shows as "--no-chain-reply-to --thread ./*" instead of from "Viswanath Puttagunta". So resent it again after fixing my command line.. Otherwise, the patch for RFCv2 is identical. Regards, Vish On 7 December 2014 at 02:08, --no-chain-reply-to --thread ./* <viswanath.puttagunta at linaro.org> wrote: > From: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> > > Hi, > > Optimizes celt_pitch_xcorr for floating point. > >...

Viswanath Puttagunta wrote: > Instead, just optimize the opus_select_arch() such that only > the first call to it takes more time, but subsequent calls to > it are much faster. This has been suggested before, but it is a bad idea. The patch posted below is not thread-safe or even re-entrant. You can argue that the results should always be the same, so it won't matter, but this is

Viswanath Puttagunta wrote: > Is the peak stack usage a complete blocker in current form? Since this only affects people who enable NE10, I don't think this is a blocker.

Hello opus-dev, Can we please have review on RFCv2? We have quite a few optimizations (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward etc) that are in my pipeline that depend on this patch series being accepted. Regards, Vish On 4 February 2015 at 12:21, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote:...

...as well? Note: Actually, I can no longer even compile latest NE10. What is working in my local setup is if I just take last patch from commit (79c3d7873) and apply it to old commit (660c6787). You can see my working NE10 code at https://git.linaro.org/people/viswanath.puttagunta/Ne10.git (branch: rfcv2_ne10_fft) My compile instructions: git clone https://github.com/projectNe10/Ne10.git cd Ne10 && mkdir build && cd build cmake -DNE10_BUILD_SHARED=ON -DCMAKE_TOOLCHAIN_FILE=../GNUlinux_config.cmake .. make -j6 Timothy/All. Having scaling capability for non-power-of-2 will work for...

On 25 February 2015 at 19:54, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Viswanath Puttagunta wrote: >> >> Can we please have review on RFCv2? We have quite a few optimizations >> (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward >> etc) that are in my pipeline that depend on this patch series being >> accepted. > > > So, trying to make progress on this... > > On an armv7l board running...

From: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> Hi, Optimizes celt_pitch_xcorr for floating point. Changes from RFCv1: - Rebased on top of commit aad281878: Fix celt_pitch_xcorr_c signature. which got rid of ugly code around CELT_PITCH_XCORR_IMPL passing of "arch" parameter. - Unified with --enable-intrinsics used by x86 - Modified algorithm to be more

Hi, Optimizes celt_pitch_xcorr for floating point. Changes from RFCv2: - Changes recommended by Timothy for celt_neon_intr.c everything except, left the unrolled loop still unrolled - configure.ac - use AC_LINK_IFELSE instead of AC_COMPILE_IFELSE - Moved compile flags into Makefile.am - OPUS_ARM_NEON_INR --> typo --> OPUS_ARM_NEON_INTR Viswanath Puttag...