Ich habe ein Projekt/Geschäft, das ich mit Ihnen besprechen möchte. Wenn Sie
interessiert sind, antworten Sie für weitere Details, wenn möglich, auf
Englisch.
Mit freundlichen Grüßen,
David Ramsden
_
Sekretärin: Christiane Aubry
_
Ich habe einen Geschäftsvorschlag für Sie, der einen beträchtlichen Betrag wert
ist (GBP 13,5 Mio.). Bei Interesse antworten Sie für weitere Details.
Geben Sie, wenn möglich, Ihr Interesse an Englisch an, um besser kommunizieren
zu können.
Mit freundlichen Grüßen,
David Ramsden
__
Ich habe ein Projekt, das ich mit Ihnen besprechen möchte. Wenn Sie
interessiert sind, antworten Sie für weitere Details, wenn möglich, auf
Englisch.
Mit freundlichen Grüßen,
David Ramsden
_
Sekretär: Stephanie Rene
___
de
Ich habe ein Projekt, das ich mit Ihnen besprechen möchte. Wenn Sie
interessiert sind, antworten Sie für weitere Details, wenn möglich, auf
Englisch.
Mit freundlichen Grüßen,
David Ramsden
_
Sekretär: Vanni Gilbert
___
dev
Ich bin Herr. Dave Ramsden und ich arbeiten mit der Bank of England
zusammen. Ich habe einen lukrativen Geschäftsvorschlag für Sie, den ich
Ihnen als Antwort auf diese E-Mail mit Einzelheiten zur Prüfung zukommen
lassen werde.
Bitte senden Sie Ihre Antwort, wenn möglich, auf Englisch, um
Ich bin Herr. Dave Ramsden und ich arbeiten mit der Bank of England zusammen.
Ich habe einen lukrativen Geschäftsvorschlag für Sie, den ich Ihnen als Antwort
auf diese E-Mail mit Einzelheiten zur Prüfung zukommen lassen werde.
Bitte senden Sie Ihre Antwort, wenn möglich, auf Englisch, um
Ich habe einen lukrativen Geschäftsvorschlag für Sie, den ich Ihnen als Antwort
auf diese E-Mail mit Einzelheiten zur Prüfung zukommen lassen werde.
Bitte senden Sie Ihre Antwort, wenn möglich, auf Englisch, um weitere
Einzelheiten zu erhalten. Warte auf deine Antwort.
Mit freundlichen Grüßen
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
as they have a concept of
> > "national technology" that can be subject to export regulations.
> >
> > From my side, I really prefer to play safe and stay out of any such
> > legal discussions.
>
> Let's be serious for a moment. If you think there are
memory overhead since one would have been sufficient.
Doesn't that make all controls for all cameras common? The struct
v4l2_ctrl_handler is part of struct v4l2_device.
Or do we:
- ditch the use of ctrl_handler in struct v4l2_device
- create and initialise a ctrl_handler per c
On Tue, Nov 05, 2019 at 04:15:50PM +0100, David Sterba wrote:
> On Sat, Nov 02, 2019 at 08:38:23AM +1100, Dave Chinner wrote:
> > On Fri, Nov 01, 2019 at 09:57:31PM +0100, Geert Uytterhoeven wrote:
> > > Hi Valdis,
> > >
> > > On Thu, Oct 31, 2019 at 2
both errors should use different values?
That horse bolted to userspace years ago - this is just formalising
the practice that has spread across multiple linux filesystems from
XFS over the past ~10 years..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Sat, Aug 31, 2019 at 06:31:45AM -0400, Valdis Klētnieks wrote:
> On Sat, 31 Aug 2019 07:54:10 +1000, Dave Chinner said:
>
> > The correct place for new filesystem review is where all the
> > experienced filesystem developers hang out - that's linux-fsdevel,
> >
a - that is completely unacceptible to users. As a
result, the quality and stability standard for merging a new
filesystem needs to be far higher that what is acceptible for
merging a new driver.
The correct place for new filesystem review is where all the
experienced f
Hi Stefan
On Fri, 28 Jun 2019 at 17:57, Stefan Wahren wrote:
>
> Hi Hans,
>
> Am 28.06.19 um 10:06 schrieb Hans Verkuil:
> > Hi Stefan,
> >
> > On 6/27/19 8:55 PM, Stefan Wahren wrote:
> >> This is an attempt to help Dave Stevenson to get all the fixes and
Hi Stefan
Firstly a huge thank you for picking this up - it's been on my to-do
list for ages, and just hasn't made it to the top.
On Fri, 28 Jun 2019 at 09:06, Hans Verkuil wrote:
>
> Hi Stefan,
>
> On 6/27/19 8:55 PM, Stefan Wahren wrote:
> > This is an attempt t
Hi Nicolas
On Thu, 27 Jun 2019 at 20:55, Nicolas Dufresne wrote:
>
> Hi Dave,
>
> Le jeudi 27 juin 2019 à 20:55 +0200, Stefan Wahren a écrit :
> > From: Dave Stevenson
> >
> > H264 header come from VC with 0 timestamps, which means they get a
> > strange tim
Hi Stefan.
On Tue, 25 Jun 2019 at 17:30, Stefan Wahren wrote:
>
> Hi Dan,
> hi Dave,
>
> Am 25.06.19 um 09:55 schrieb Dan Carpenter:
> > On Tue, Jun 25, 2019 at 12:13:15AM +0200, Stefan Wahren wrote:
> >> The commit 52c4dfcead49 ("Staging: vc04_service
> > The patch has been merged, would you mind to send a documentation patch
> > for the vmcoreinfo, which is added recently in
> > Documentation/kdump/vmcoreinfo.txt
> >
> > A brief description about how this vmcoreinfo field is used is good to
> > have.
> >
>
> Turns out, it was already docume
ack) would under some condicions
> result in a kernel panic when dumping them.
>
> Cc: Andrew Morton
> Cc: Dave Young
> Cc: "Kirill A. Shutemov"
> Cc: Baoquan He
> Cc: Omar Sandoval
> Cc: Arnd Bergmann
> Cc: Matthew Wilcox
> Cc: Michal Hocko
> C
On 02/28/19 at 11:45am, Andrew Morton wrote:
> On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote:
>
> > This series have been in -next for some days, could we get this in
> > mainline?
>
> It's been in -next for two months?
Should be around 3 months
>
&g
flags.h | 2 +-
> kernel/crash_core.c | 2 ++
> kernel/power/snapshot.c | 17 +++-
> tools/vm/page-types.c| 2 +-
> 11 files changed, 90 insertions(+), 40 deletions(-)
>
> --
> 2.17.2
>
This series
t;
> [8.087691] raspberrypi-firmware soc:firmware: Attached to firmware
> from 2019-01-09 20:07
>
> Something like "attached to extended/reduced/whatecer firmware from
> -XX-XX"
A very valid suggestion.
I've made the firmware
468
- The driver has then tried to pass some buffers to MMAL / VCHI which
tries adding them to an invalid list.
I'm investigating why the firmware is failing to enable the camera
initially, and then look at cleaning up the error handling.
Dave
> Peter
>
> [ 231.121
logically offline memory (pages kept fake offline while
> onlining a section via online_page_callback) would under some condicions
> result in a kernel panic when dumping them.
>
> Cc: Andrew Morton
> Cc: Dave Young
> Cc: "Kirill A. Shutemov"
> Cc: Baoquan He
> Cc: O
ferent opinion :)
>
> Cc: Andrew Morton
> Cc: Dave Young
> Cc: "Kirill A. Shutemov"
> Cc: Baoquan He
> Cc: Omar Sandoval
> Cc: Arnd Bergmann
> Cc: Matthew Wilcox
> Cc: Michal Hocko
> Cc: "Michael S. Tsirkin"
> Signed-off-by: David Hi
Hi Stefan
On Sun, 28 Oct 2018 at 08:31, Stefan Wahren wrote:
>
> Hi Dave,
>
> > Dave Stevenson hat am 26. Oktober 2018 um
> > 19:15 geschrieben:
> >
> >
> > Thanks Stefan.
> > I've picked up your latest patches which mean I can get the driver
On Thu, 18 Oct 2018 at 10:38, Stefan Wahren wrote:
>
> Am 18.10.2018 um 11:22 schrieb Dave Stevenson:
> > On Wed, 17 Oct 2018 at 17:51, Peter Robinson wrote:
> >>>>>> Drop various pieces of dead code from here and there to get rid of
> >>>>>>
>
> > Given that the new VCSM service is a rewrite, it's not clear to me that
> > importing the old VCSM driver is a win. But maybe we should go raid
> > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab
> > the new drivers. Upstreaming t
The new vcsm uses the same VCHI service as the existing downstream vc_sm driver.
The video codec driver don't use any VCHI functionality over and above
the camera. It goes via a slightly extended version of the
mmal-vchiq.c, which I have split out into a shared module.
> On the othe
88,7 +588,6 @@ static int ctrl_set_colfx(struct bm2835_mmal_dev *dev,
> >
> > control = &dev->component[MMAL_COMPONENT_CAMERA]->control;
> >
> > - dev->colourfx.enable = (ctrl->val & 0xff00) >> 8;
> > dev->colourfx.enable = ctrl-&
On Mon, 8 Oct 2018 at 18:09, Stefan Wahren wrote:
>
> Hi Dave,
>
> > Dave Stevenson hat am 8. Oktober 2018 um
> > 18:51 geschrieben:
> >
> >
> > Hi Stefan.
> >
> > Thanks for forwarding as the linux-rpi-kernel list hasn't sent it
On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
> It is more than just memmaps (e.g. forking udev process doing memory
> onlining also needs memory) but yes, the main idea is to make the
> onlining synchronous with hotplug.
That's a good theoretical concern.
But, is it a problem we need to solve
> How should a policy in user space look like when new memory gets added
> - on s390x? Not onlining paravirtualized memory is very wrong.
Because we're going to balloon it away in a moment anyway?
We have auto-onlining. Why isn't that being used on s390?
> So the type of memory is very importa
It's really nice if these kinds of things are broken up. First, replace
the old want_memblock parameter, then add the parameter to the
__add_page() calls.
> +/*
> + * NONE: No memory block is to be created (e.g. device memory).
> + * NORMAL: Memory block that represents normal (boot or hotp
#x27;s
v4l2_ctrl_new_int_menu that does). That means the correct fix is to
define the max value using the relevant enum (in this case
V4L2_CID_POWER_LINE_FREQUENCY_AUTO) and remove the array.
The same is true for V4L2_CID_MPEG_VIDEO_BITRATE_MODE - max should be
V4L2_MPEG_VIDEO_BITRATE_MODE_CBR, and
image should be reasonable.
Have you tried it with "v4l2-ctl --stream-mmap=3 --stream-count=1
--stream-to=capture.jpg" and looked at the output? In all but fairly
bright conditions I'd expect to get a very dark image.
Dave
> Signed-off-by: Stefan Schake
> ---
> driv
On 05/16/2018 04:43 AM, Christoph Hellwig wrote:
> Use remove_proc_subtree to remove the whole subtree on cleanup, and
> unwind the registration loop into individual calls. Switch to use
> proc_create_seq where applicable.
>
> Signed-off-by: Christoph Hellwig
Acked-by:
On 11 May 2018 at 00:12, Stefan Schake wrote:
> The overlay code is non-functional since it relies on firmware control
> of the HVS.
>
> Signed-off-by: Stefan Schake
> ---
> Dave, does this match your understanding?
Yes, the overlay only works if you are not running the vc4
is a straightforward conversion from calling
> filemap_write_and_wait_range in their fsync operation to calling
> file_write_and_wait_range.
>
> Signed-off-by: Jeff Layton
Acked-by: Dave Kleikamp
(for jfs)
> ---
> arch/powerpc/platforms/cell/spufs/file.c | 2 +-
> drivers/s
mbers to build staging, then you end up with broken
staging, I'd like to wait for Daniel to get back from holidays to
consult on whether we should just put this in non-staging so we don't
lose it down the cracks.
The most important thing is for the driver to be at
On 16 March 2017 at 05:11, Eric Anholt wrote:
> Greg KH writes:
>
>> On Wed, Mar 15, 2017 at 03:32:56PM +, Dave Stevenson wrote:
>>> You've got a reason. It's GPLv2 licenced code so I have no control
>>> over what happens to it.
>>> Everyw
On 15 March 2017 at 10:36, Dan Carpenter wrote:
> On Wed, Mar 15, 2017 at 10:06:11AM +0000, Dave Stevenson wrote:
>> On 15 March 2017 at 05:08, Greg KH wrote:
>> > On Tue, Mar 14, 2017 at 03:32:43PM +, Dave Stevenson wrote:
>> >> NACK.
>> >> Ph
On 15 March 2017 at 05:08, Greg KH wrote:
> On Tue, Mar 14, 2017 at 03:32:43PM +0000, Dave Stevenson wrote:
>> NACK.
>> Phil asked for a couple of changes, although functionally identical.
>> I'll send a patch when I get a chance.
>
> What do you mean, "whe
NACK.
Phil asked for a couple of changes, although functionally identical.
I'll send a patch when I get a chance.
Your existing workaround has removed the immediate issue of the
overflow, this was only cleaning things up to actually match the
original API.
Dave
On 14 March 2017 at
On 10 March 2017 at 11:16, Michael Zoran wrote:
> On Fri, 2017-03-10 at 11:11 +0000, Dave Stevenson wrote:
>> On 10 March 2017 at 05:08, Michael Zoran wrote:
>> > The code that queries properties on the camera has a check
>> > for buffer overruns if the firmware
On 10 March 2017 at 05:08, Michael Zoran wrote:
> The code that queries properties on the camera has a check
> for buffer overruns if the firmware sends too much data. This
> check is incorrect, and during testing I was seeing stack corruption.
>
> I believe this error can actually happen in norm
On 8 March 2017 at 13:46, Michael Zoran wrote:
> On Wed, 2017-03-08 at 13:19 +0000, Dave Stevenson wrote:
>
> Hi Michael.
>
> The original issue was on Pi1 with H264 or MJPEG streams. Buffer sizes were
> small enough to fit in the L1 cache and the relevant sections weren'
Hi Hans.
On 06/02/17 12:58, Hans Verkuil wrote:
On 02/06/2017 12:37 PM, Dave Stevenson wrote:
Hi Hans.
On 06/02/17 09:08, Hans Verkuil wrote:
Hi Eric,
Great to see this driver appearing for upstream merging!
See below for my review comments, focusing mostly on V4L2 specifics
Hi Mauro.
Can I just say that I'm not attempting to upstream this, others are.
I've just answered questions raised.
On 06/02/17 12:37, Mauro Carvalho Chehab wrote:
Em Sun, 5 Feb 2017 22:15:21 +
Dave Stevenson escreveu:
If the goal was to protect some IP related to the sensor
Hi Hans.
On 06/02/17 09:08, Hans Verkuil wrote:
Hi Eric,
Great to see this driver appearing for upstream merging!
See below for my review comments, focusing mostly on V4L2 specifics.
On 01/27/2017 10:54 PM, Eric Anholt wrote:
- Supports raw YUV capture, preview, JPEG and H264.
- Uses videobu
e public).
That doesn't seem to fit very well into V4L2 which expects that it can
see all the detail, so there are a few nasty spots to shoe-horn it in.
If there are better ways to solve the problems, then I'm open to them.
Thanks
Dave
On 03/02/17 18:59, Mauro Carvalho Chehab wrot
Fix checkpatch warning: Macros with flow control statements should be avoided
Because Macros with flow control statements (goto and return) are
not very nice to read as any flow movement is unexpected.
Signed-off-by: Siddhi Dave
---
drivers/staging/dgnc/dgnc_sysfs.c | 20
Fix checkpatch warning: Macros with flow control statements should be avoided
Because Macros with flow control statements (goto and return) are
not very nice to read as any flow movement is unexpected.
Signed-off-by: Siddhi Dave
---
drivers/staging/dgnc/dgnc_sysfs.c | 20
Fix checkpatch warning: Macros with flow control statements should be avoided
Because Macros with flow control statements (goto and return) are
not very nice to read as any flow movement is unexpected.
Signed-off-by: Siddhi Dave
---
drivers/staging/dgnc/dgnc_sysfs.c | 20
On 10/11/2016 04:50 PM, Ruchi Kandoi wrote:
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages. mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address
Good day to you, this email is to inform you that i and my wife have a donation
check for you so please reply back for more details.
Regards
Dave Dawes
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman
tency somewhere.
>
> I think the whole thing here is that you misinterpreted what Eric said.
>
> He is not arguing that some regression did, or did not, happen.
>
> He instead was making the basic statement about the fact that due to
> the lack of paralellness a single stream TCP case is harder to
> optimize for high speed NICs.
>
> That is all.
We recently had a regression tracked down in a similiar area that was
because of link order.
Dave.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 08/02/2015 10:53 PM, Wang, Biao wrote:
> Consider the following case:
> Task A trigger lmk with a lock held, while task B try to
> get this lock, but unfortunately B is the very culprit task lmk select to
> kill. Then B will never be killed, and A will forever select B to kill.
> Such dead lock
This is a patch to the rtw_debug.c file that fixes styling errors relating to
new lines after variable declarations.
Signed-off-by: Dave Perez
---
drivers/staging/rtl8188eu/core/rtw_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8188eu/core
This is a patch to the rtw_debug.c file that fixes styling errors relating to
new lines after variable declarations.
Signed-off-by: Dave Perez
---
drivers/staging/rtl8188eu/core/rtw_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8188eu/core
ers/gpu/drm.
>
> Signed-off-by: Philipp Zabel
> ---
FYI I've merged this into drm-next, which I think is probably the best place.
Dave.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
to see if we have any of the
broken case in the tree :-)
as for consistency, pci_dev vs usb_device :-P
Dave.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
7;re going to have to delete the driver, as we don't
want staging to become a permanent place for unfinished code.
Hi Kristina,
I'm not working on anything for wlags49_h2.
Thanks for asking,
Dave.
___
devel mailing list
de...@linuxdr
dentation mess, but
indentation is the least of this patch's problems.
if that alloc_skb fails, going around the loop again is pointless, and
harmful. (we'll oops right below that added bracket).
on failure, this should be returning 0 so that the caller
handles the failure appropriately
Changes since RFC:
>> > > - Rebased onto current staging-next
>> > > - Removed an unrelated change to ipu_pixelformat_to_colorspace
>> > > - Avoided moving around the IPU_PIX_FMT_GBR24 #define
>> >
>> > Ack
On Mon, Feb 17, 2014 at 11:13:16PM +0300, Dan Carpenter wrote:
> On Mon, Feb 17, 2014 at 02:59:19PM -0500, Dave Jones wrote:
> > On Mon, Feb 17, 2014 at 10:56:06PM +0300, Dan Carpenter wrote:
> > > There are a couple paths where we don't check how much data we copy b
little functions ?
Dave
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
I was doing some code audits looking at scattergather uses, and noticed
that update() in drivers/staging/rtl8192u/ieee80211/digest.c uses
sg.page which doesn't exist any longer, so this can't possibly compile.
Turns out that digest.c is actually unused. It doesn't get referenced
in a Makefile or
On 01/21/2014 12:02 PM, Dilger, Andreas wrote:
> The Lustre allocation macros track the memory usage across the whole
> filesystem,
> not just of a single structure that a mempool/slab/whatever would do.
> This is
> useful to know for debugging purposes (e.g. user complains about not having
> enoug
, I didn't look at -next.
thanks,
Dave
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Sat, Oct 19, 2013 at 07:59:55PM +0900, Akira Hayakawa wrote:
> Dave,
>
> # -EIO retuned corrupts XFS
> I turned up
> lockdep, frame pointer, xfs debug
> and also changed to 3.12.0-rc5 from rc1.
>
> What's changed is that
> the problem we discussed in pr
On Wed, Oct 16, 2013 at 09:17:40PM +0900, Akira Hayakawa wrote:
> Dave
>
> > XFS shuts down because you've returned EIO to a log IO. That's a
> > fatal error. If you do the same to an ext4 journal write, it will do
> > the equivalent of shut down (e.g. compla
On Wed, Oct 16, 2013 at 07:34:38PM +0900, Akira Hayakawa wrote:
> Dave
>
> > Akira, can you please post the entire set of messages you are
> > getting when XFS showing problems? That way I can try to confirm
> > whether it's a regression in XFS or something else.
>
ce drivers that no
other filesystem exposes, and so when a new block device driver gets
tested with XFS and we start seeing memory corruption symptoms, it's
a fair bet that it's not XFS that is causing it
Just sayin'.
---
Akira, can you please post the entire set of
On Sat, Oct 05, 2013 at 04:51:16PM +0900, Akira Hayakawa wrote:
> Dave,
>
> > That's where arbitrary delays in the storage stack below XFS cause
> > problems - if the first FUA log write is delayed, the next log
> > buffer will get filled, issued and delayed, a
optimisations should be done at the
point where they are issued - any attempt to further optimise them
by adding delays down in the stack to aggregate FUA operations will
only increase latency of the operations that the issuer want to have
complete as fast as possible
might be
capable of executing hundreds of synchronous operations per
barrier_deadline_ms..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello,
Is this an active email address? If yes,please send a reply..Checking for
confirmation.
Thanks!
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello,
Is this an active email address? If yes,please send a reply..Checking for
confirmation.
Thanks!
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 07/25/2013 08:15 AM, Kay Sievers wrote:
> Complexity, well, it's just a bit of code which belongs in the kernel.
> The mentioned unconditional hotplug loop through userspace is
> absolutely pointless. Such defaults never belong in userspace tools if
> they do not involve data that is only availa
On 07/25/2013 04:14 AM, KY Srinivasan wrote:
> As promised, I have sent out the patches for (a) an implementation of an
> in-kernel API
> for onlining and a consumer for this API. While I don't know the exact
> reason why the
> user mode code is delayed (under some low memory conditions), what i
On 07/24/2013 02:29 PM, K. Y. Srinivasan wrote:
> /*
> - * Wait for the memory block to be onlined.
> - * Since the hot add has succeeded, it is ok to
> - * proceed even if the pages in the hot added region
> - * have not been "onlin
On 07/24/2013 12:45 PM, KY Srinivasan wrote:
> All I am saying is that I see two classes of failures: (a) Our
> inability to allocate memory to manage the memory that is being hot added
> and (b) Our inability to bring the hot added memory online within a reasonable
> amount of time. I am not sure
On 07/23/2013 10:21 AM, KY Srinivasan wrote:
>> You have allocated some large, physically contiguous areas of memory
>> under heavy pressure. But you also contend that there is too much
>> memory pressure to run a small userspace helper. Under heavy memory
>> pressure, I'd expect large, kernel al
On 07/23/2013 08:54 AM, KY Srinivasan wrote:
>> > Adding memory usually requires allocating some large, contiguous areas
>> > of memory for use as mem_map[] and other VM structures. That's really
>> > hard to do under heavy memory pressure. How are you accomplishing this?
> I cannot avoid failure
On 07/23/2013 07:52 AM, KY Srinivasan wrote:
> The current scheme of involving user
> level code to close this loop obviously does not perform well under high
> memory pressure.
Adding memory usually requires allocating some large, contiguous areas
of memory for use as mem_map[] and other VM str
87 matches
Mail list logo
